SPF, DKIM and DMARC: Email Authentication Done Properly

Publish an SPF record, turn on DKIM signing in your mail platform, then publish DMARC at p=none and read the reports for a month. That is the first week of work and it is most of the benefit. The part everyone rushes, moving to p=reject, is the part the rewritten DMARC standard is now explicitly cautious about, and for good reason: if your staff post to mailing lists, reject will bounce their legitimate mail.

What each of the three actually does

The three mechanisms answer different questions, and the confusion that makes people give up usually comes from treating them as three versions of the same thing.

DMARC is the only one of the three that the recipient acts on in a way you control, and it is the only one that reports back to you. That reporting is the real prize. Within a month of publishing a DMARC record you will know every system sending mail as your domain, including the two nobody remembered.

The DMARC specification changed in 2026

DMARC spent eleven years as RFC 7489, an informational document rather than a standard. In May 2026 the IETF published RFC 9989, together with RFC 9990 and RFC 9991 covering aggregate and failure reporting, and obsoleted RFC 7489. The protocol version string is still v=DMARC1, so existing records keep working, but several details changed in ways worth knowing before you copy a 2021 blog post.

The change with the most practical bite is not a tag. RFC 9989 states plainly that domains hosting general users who send routine email are likely to create significant interoperability problems if they publish p=reject, and that such domains SHOULD NOT do so. It also states that any domain publishing reject MUST NOT rely solely on SPF and MUST apply valid DKIM signatures, because DKIM survives relaying and SPF generally does not.

SPF, and the ten-lookup limit that breaks it

SPF lists the servers allowed to send mail using your domain in the envelope sender. The record is one TXT entry at your domain apex and looks like this for a business using Google Workspace plus one marketing platform:

• v=spf1 include:_spf.google.com include:sendgrid.net -all

Two decisions matter. The first is the final mechanism. -all is a hard fail, meaning anything not listed is unauthorised; ~all is a soft fail. Start with ~all while you are still discovering senders, and move to -all once your DMARC reports are quiet. The second is the lookup budget, and it is where most broken records come from.

RFC 7208 is explicit: implementations MUST limit the total number of DNS-querying terms to 10 during evaluation, and MUST return permerror if that limit is exceeded. The terms that count are include, a, mx, ptr, exists and the redirect modifier. The ones that do not count are ip4, ip6 and all. The specification also recommends limiting void lookups, meaning queries that return no answer, to two, and allowing at least 20 seconds for evaluation.

DKIM: selectors, key length and surviving a forward

DKIM adds a cryptographic signature over selected headers and the message body. The receiving server fetches your public key from DNS, verifies the signature, and knows two things: the message was signed by someone holding your private key, and the signed parts have not changed in transit.

In practice you enable DKIM in your mail platform’s admin console, it generates a key pair and gives you a TXT record to publish at a selector such as google._domainkey.yourdomain.com. The selector exists so you can hold several keys at once, which is what makes rotation possible: publish the new selector, switch signing to it, then remove the old one a fortnight later.

Two details are worth getting right. Key length first: Google requires a DKIM key of at least 1024 bits for mail to personal Gmail accounts and recommends 2048 bits where the DNS provider supports it. Some older DNS interfaces refuse long TXT values, which is where the 1024-bit fallback came from; if yours does, split the value across strings rather than shortening the key. Second, every system that sends as your domain needs its own DKIM setup. The invoicing tool, the CRM and the newsletter platform each sign with their own selector, and each one you skip becomes a DMARC failure in your reports.

DKIM matters more than SPF for one specific reason, stated in RFC 9989: DKIM signatures generally remain valid when a message is relayed, while SPF usually fails because the relaying server’s IP address is not in your record. That asymmetry is the whole argument for signing everything before you tighten any policy.

DMARC: none, then quarantine, then a careful decision

DMARC ties the other two to the domain the recipient actually sees, and tells receivers what to do when neither SPF nor DKIM aligns with it. Start here:

• v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

That publishes a monitoring policy and asks receivers to send you aggregate reports. The reports arrive as compressed XML, which is unreadable by hand; use any DMARC report analyser, including the free tiers, to turn them into a list of sending sources. Give it a month. RFC 9989 recommends exactly this sequence for domains that want to tighten: publish p=none for at least a month, then p=quarantine for an equally long period, and compare the disposition results before going further.

Notice the third row. Publishing np=reject costs you nothing and closes a real gap, because nobody sends legitimate mail from a subdomain that does not exist. If you only do one thing beyond monitoring, do that.

Most domains never finish. Palisade’s State of DMARC 2026 study resolved records for 99,310 domains on 13 August 2026 and found 58.1% published a DMARC policy, but only 64.0% of those were enforcing it with quarantine or reject. Just over a third of domains with DMARC, 36.0%, were still at p=none, and 20.5% had a DMARC record with no rua tag at all, meaning they publish a policy and collect no reports.

The 20.5% figure is the one to avoid joining. A DMARC record without rua is a policy published blind: you have told the world’s receivers what to do with your failing mail without giving yourself any way to see what is failing.

Where forwarding and mailing lists break things

This is the section most guides skip, and it is the reason email authentication projects end in an angry phone call. Two legitimate situations break authentication through no fault of yours.

Plain forwarding. Somebody has an alias at a university or an association that relays to their real mailbox. When your message arrives at the final destination, the connecting IP address belongs to the relay, not to you, so SPF fails. RFC 9989 uses exactly this example. The DKIM signature usually survives, which is why a domain at p=reject that relies only on SPF will reject its own legitimate mail.

Mailing lists. Discussion lists commonly add a footer or a subject tag, which invalidates the DKIM signature, and they resend from their own servers, which fails SPF. The result is that a message your colleague genuinely wrote gets rejected by every subscriber whose provider honours your policy. ARC, specified in RFC 8617, exists to let the list vouch for the original result, but it is experimental and support is uneven. This is precisely why RFC 9989 advises domains with general users who post to lists not to publish reject.

The practical resolution for a small business is usually a split. Keep your main domain, the one humans send from, at p=quarantine. Send bulk and transactional mail from a dedicated subdomain such as mail.yourdomain.com and set that one to p=reject. Bulk senders do not post to mailing lists, so the interoperability problem disappears, and the subdomain is the identity most worth protecting from impersonation anyway.

What Gmail and Outlook now require

Both large consumer providers now enforce authentication, and the thresholds are the same number on both sides.

Google’s sender guidelines have required, since 1 February 2024, that every sender to personal Gmail accounts sets up SPF or DKIM, publishes valid forward and reverse DNS for its sending hosts, uses TLS for transmission, keeps the spam rate reported in Postmaster Tools below 0.3%, and formats messages according to RFC 5322. Senders of more than 5,000 messages a day must do more: SPF and DKIM, a DMARC record which may be as permissive as p=none, From alignment with either the SPF or the DKIM domain, and one-click unsubscribe on marketing mail. Messages that fail authentication may be marked as spam or rejected with a 5.7.26 error.

Microsoft announced equivalent requirements for Outlook.com, Hotmail, Live and MSN addresses in April 2025, with enforcement from 5 May 2025. Domains sending 5,000 or more messages a day to those consumer mailboxes need SPF and DKIM to pass and a DMARC record in place. Non-compliant mail was first routed to Junk, with outright rejection to follow.

If you send fewer than 5,000 messages a day, none of the high-volume rules bind you. Do it anyway. The thresholds are where enforcement starts, not where the spoofing risk starts, and your domain’s reputation is built long before you cross them.

A two-week plan and the three checks afterwards

Two weeks of mostly waiting, with about four hours of actual work.

1. Day one. List every system that sends mail as your domain: the mail platform, the CRM, the invoicing tool, the newsletter, the website contact form, the helpdesk. Ask finance and marketing, because you will miss two.
2. Day one. Publish SPF with ~all and every current sender included. Count your DNS-querying terms and stay at or below ten.
3. Day two. Enable DKIM in each sending platform and publish each selector. This is the longest task and the one worth doing thoroughly.
4. Day two. Publish v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com and point it at a mailbox somebody reads.
5. Day three. Add np=reject for non-existent subdomains. No legitimate mail is affected.
6. Week two onwards. Read the aggregate reports. Fix any legitimate source that is not DKIM-signed. Only then consider p=quarantine, and give that a month before you think about reject.

Afterwards, three checks keep it honest. Re-count your SPF lookups whenever you add a vendor. Re-read a month of DMARC reports once a quarter, because new sending tools appear without anyone telling you. And when you retire a platform, remove its SPF include and its DKIM selector, since a dangling selector is a key you no longer control.

Email authentication stops other people sending as you. It does nothing about mail arriving at your staff, which is a separate job covered in our guide to stopping phishing attacks, and nothing about a stolen password, which is what our multi-factor authentication guide is for. If you would like the records set up and the first month of reports read for you, our cybersecurity services include exactly that, delivered remotely.

If you want SPF, DKIM and DMARC published correctly the first time, with the reports read and the staging done in the order the standard recommends, we can set it up and hand you the records. Get in touch with Eudora Technology to talk about your project.