SPF, DKIM and DMARC explained, step by step

Este contenido está en inglés.

SPF, DKIM and DMARC are three DNS-based checks that help receiving mail servers decide whether a message really came from your domain. Set up correctly, they reduce the chance of your email landing in spam and make it harder for others to impersonate you. This guide explains what each one does, shows example records, and gives a rollout order that avoids breaking legitimate mail, with details checked against Google and RFC documentation in October 2026.

Por Valtrinity. Actualizado el 18 de octubre de 2026.

Why email authentication matters

Email was designed without a built-in way to prove who sent a message. Anyone can put your domain in the From line of an email, and without extra checks a receiving server has little to go on. SPF, DKIM and DMARC add those checks using records that you publish in DNS, the same system that points your domain at your website.

The benefits are practical. Your genuine messages, such as order confirmations, contact form replies and newsletters, are more likely to be accepted. Attempts to spoof your domain are more likely to be rejected or flagged. And the reports DMARC produces show you every system that sends mail in your name, including ones you had forgotten about.

There is also a rule-of-the-road element. Google requires senders to set up SPF or DKIM, and anyone sending more than 5,000 messages a day to Gmail addresses must set up SPF, DKIM and DMARC. Even if you send far less, following the same practice is sensible.

SPF: which servers may send for your domain

Sender Policy Framework, or SPF, is a TXT record on your domain that lists the servers and services allowed to send mail using that domain. When a message arrives, the receiving server looks at the envelope sender domain, fetches its SPF record and checks whether the connecting server is on the list.

A record always starts with v=spf1. After that come the mechanisms. Google's example for a domain that sends only through Google Workspace is v=spf1 include:_spf.google.com ~all. The include mechanism pulls in the list belonging to another provider, and the closing all mechanism says what to do with anything not listed. A tilde before all, known as a soft fail, means messages from other servers should be treated with suspicion, while a hyphen before all, a hard fail, asks receivers to reject them.

A domain that sends through its own server and one marketing service might publish v=spf1 ip4:203.0.113.25 include:spf.mailprovider.example ~all, where the address is a documentation example and the include name is a placeholder for the value your provider gives you.

• Publish only one SPF record per domain. Two separate records make the result a permanent error, so merge everything into a single line.
• SPF evaluation may cause at most 10 DNS-querying terms. The include, a, mx, ptr and exists mechanisms and the redirect modifier all count, and exceeding the limit produces a permerror.
• Void lookups, which are queries that return no answer, should be limited to two.
• SPF checks the envelope sender, not the visible From address, which is why DMARC alignment matters.

DKIM: a signature that proves the message was not altered

DomainKeys Identified Mail, or DKIM, works with a pair of cryptographic keys, one kept by the sender and one published. Your mail system signs each outgoing message with a signing key and adds the signature to the headers. You publish the matching public key in DNS, and receiving servers use it to check that the signature is valid and the signed parts of the message were not changed in transit.

The public key lives in a TXT record at a name made of a selector, the label _domainkey and your domain. For a provider that gives you the selector selector1, the host would be selector1._domainkey.example.com. The value looks like v=DKIM1; k=rsa; p= followed by a long string of characters that your provider generates. You copy that string exactly as supplied.

Selectors let you have several keys at once, for example one per sending service, and rotate them without downtime. Google's guidance for bulk senders is to use a key of 1024 bits or longer, and it recommends 2048 bits if your provider supports it. Your provider normally handles key generation and signing, so your job is mainly to publish the record it gives you and confirm it validates.

DMARC: tying SPF and DKIM together with a policy

Domain-based Message Authentication, Reporting and Conformance, or DMARC, builds on the other two. It asks receivers to check that the domain in the visible From address aligns with the domain that passed SPF or DKIM, and it tells them what to do when the checks fail. It also asks them to send you reports.

A DMARC record is a TXT record at _dmarc.example.com. The policy tag p has three values. With none, the message is delivered normally and the result is logged in reports. With quarantine, failing messages go to the recipient's spam folder. With reject, they are refused. The rua tag lists the addresses that should receive aggregate reports, each with the mailto: prefix.

Google's setup guidance suggests prerequisites worth noting: set up SPF and DKIM first and allow at least 48 hours for them to start authenticating messages before you enable DMARC. If you send to Gmail in bulk, the From domain must align with the SPF or DKIM domain for DMARC to pass, although the policy may be set to none.

A step-by-step rollout order

The most reliable way to deploy is slowly. Jumping straight to a strict policy can block your own invoices or newsletters if one sending service is not yet covered. Follow this sequence and move to the next step only when the previous one is working.

• Step 1: List every service that sends email as your domain, including your main mailbox provider, website contact forms, newsletter tools, billing systems and support desks.
• Step 2: Create a single SPF record that includes each service, and publish it as a TXT record on the root of your domain.
• Step 3: Turn on DKIM signing in each service and publish the public key records it asks for.
• Step 4: Publish a DMARC record with p=none and a rua address, for example v=DMARC1; p=none; rua=mailto:[email protected].
• Step 5: Read the reports for a few weeks, identify any legitimate sender that fails, and fix its SPF or DKIM setup.
• Step 6: Move to p=quarantine, optionally using the pct tag to apply it to a share of messages first, then raise it.
• Step 7: Move to p=reject when you are confident that all legitimate mail passes.

Reading DMARC reports

Aggregate reports arrive as compressed XML files, regularly from receiving providers. They are not meant to be read by hand, and the volume can be high, so use a dedicated mailbox or group rather than a personal inbox. Many DMARC reporting services turn the XML into tables that show each sending source, how many messages it sent, and whether they passed SPF, DKIM and alignment.

What you are looking for is any source that sends mail as your domain and fails. Sometimes it is an unauthorised sender, which is exactly what DMARC is meant to expose. More often it is a legitimate service that was never added to SPF or never had DKIM enabled. Fix those before tightening the policy.

If the reporting address is on a different domain from the one being reported on, that domain needs its own DNS record to accept the reports, so check your provider's documentation if reports are not arriving.

Common mistakes and how to fix them

The most common SPF mistake is publishing two records, usually because a new service told you to add its own. Combine them into one line, with a single v=spf1 at the start and a single all mechanism at the end. The second most common is exceeding the limit of 10 lookups by stacking many include mechanisms. Remove services you no longer use, or ask providers whether they offer a flattened or shared include.

For DKIM, errors usually come from copying the key with a missing character or an added space, or from some DNS hosts automatically appending your domain name to the host field, which produces a name like selector1._domainkey.example.com.example.com. After saving, check the final name that the host displays.

For DMARC, a typical error is placing the record at the wrong name, or using a policy of reject before alignment is working. Another is forgetting that forwarded mail can break SPF, since the forwarding server is not in your record. DKIM signatures usually survive forwarding, which is one reason to have both in place.

Testing and keeping it up to date

After publishing, query your records to confirm they are visible and well formed. A DNS lookup shows the raw TXT records, and an email DNS checker can evaluate SPF, DKIM selectors and DMARC together and flag problems such as multiple SPF records. Then send a real test message to an address you control and examine the headers, where the authentication results show pass or fail for each method.

Treat your configuration as something to review, not a one-time job. Whenever you add a new sending service, update SPF and enable DKIM for it before you start using it. When you drop one, remove it from SPF. Monitor your reports, and for bulk senders keep an eye on spam rates in Google Postmaster Tools, where Google asks senders to stay below 0.30% and recommends aiming below 0.10%.

Herramientas mencionadas en esta guía

Preguntas frecuentes