Fixing this on any email provider
The three records are the same everywhere, and two of them have nothing to do with your email provider.
The three records are the same everywhere, and two of them have nothing to do with your email provider. SPF and DMARC live purely in DNS. Only DKIM has to be switched on by whoever runs your email.
Where each change is made
- SPF — a TXT record at your DNS provider.
- DMARC — a TXT record at your DNS provider.
- DKIM — your email provider generates the key and gives you a record, which you then publish at your DNS provider.
Those can be two different companies. The check tells you who hosts your DNS, and it's often not the company you bought the domain from.
1. Ask your email provider to enable DKIM
Wording you can copy: "Please enable DKIM signing for our domain, signing with our own domain rather than yours, and send me the DNS record to publish."
That last part matters. Some providers sign outgoing mail with their domain by default, which passes DKIM on its own but fails DMARC. If your check said DKIM couldn't be confirmed, this is the question to ask.
It's first for a reason. When a message is forwarded on — by a role address like
finance@ that points at whoever currently holds the job, or an old alumni address
that redirects — SPF generally breaks, because the message now reaches the recipient from the
forwarder's server rather than from your provider's, while a DKIM signature survives that trip
intact. So DKIM is what keeps that mail passing once you tighten the policy, and a domain relying
on SPF alone has nothing protecting it.
Mailing lists are the harder case, and DKIM does not rescue them: most lists add a footer or tag
the subject, which invalidates the signature as well. That is why list software rewrites the
From: header, and why the advice further down is to stop at quarantine.
2. SPF
One TXT record at your domain root listing everything allowed to send as you. Your provider
will tell you their include: value. If you already have an SPF record, edit
that one rather than adding a second, and add to it rather than pasting over it, or
you'll drop the senders already listed. The shape is:
v=spf1 include:their-spf-host.example ~all
Three constraints: only ever one SPF record, keep it under ten DNS lookups,
and end it with ~all or -all rather than +all.
The record above ends ~all, which tells receivers that mail from anywhere
unlisted is suspect without asking them to refuse it. There is a stricter ending,
-all, which does ask them to refuse it.
~all is a perfectly reasonable place to stay. The reason is
forwarding again: when a message is forwarded on, SPF fails because it now arrives from the
forwarder's server, and a receiver can act on an SPF hard fail during delivery — before it
ever looks at the DKIM signature that survived the trip. Those refusals don't appear in your
DMARC reports either, so you wouldn't find out. With ~all that mail still gets
through on DKIM, which is what step 1 was for. Your protection against forgery comes
from your DMARC policy, and DMARC treats a soft fail and a hard fail identically.
-all is worth it if you are confident every legitimate sender is listed and
nobody forwards your mail — a domain used only for bulk sending, say. It also takes effect
the moment you publish it, with no monitoring stage of the kind DMARC gives you.
3. DMARC
TXT record with the host _dmarc. Start with monitoring:
v=DMARC1; p=none; rua=mailto:[email protected];
That address needs to be a mailbox that exists, or one supplied by a reporting service. On a
domain with no DMARC policy in force, p=none changes nothing about delivery.
One thing to check before publishing it. If the check says this exact name
is already inheriting quarantine or reject from a parent domain, then
publishing a weaker policy here replaces that inherited protection — and you don't want
this record. p=none turns it off entirely; p=quarantine weakens
inherited reject. Inheriting a parent's p=none, or a parent
whose sp= already sets none for its subdomains, is a different case —
there is nothing to lose and the record is fine to add. Go by the effective policy the check
reports for this name, not by what the parent's record says on its own.
Reports arrive only from receivers that choose to send them, and if the address is on someone else's domain that domain has to authorise it first — so a quiet period means "check the address" rather than "nobody is forging you". The ones that do arrive are zipped XML attachments, built for software and not realistically readable by hand. See making DMARC reports readable for free and nonprofit-priced options.
Once the reports show every legitimate sender passing, move to p=quarantine.
Going in stages is what lets you find legitimate senders before they start bouncing. A short
clean window can still miss senders that only go out quarterly or once a year — ask who uses
the domain before you tighten.
Quarantine is far enough for most organisations. The stricter
p=reject refuses forged mail rather than spam-foldering it, but the current DMARC
standard advises against it for ordinary organisations, since a mailing list relays your
message from its own servers while leaving your address in the From line, so genuine mail sent
that way is refused alongside the forgeries.
If another organisation sends email as you
This is common where a management company or fiscal sponsor handles some of your mail. Their DKIM signs as their domain, which fails DMARC alignment even though their own setup is fine.
The fix is on their side: they add your domain and publish DKIM for it, so the signature
carries your domain rather than theirs. Find those senders during the monitoring period —
under p=quarantine their mail goes to spam, and under p=reject it is
refused, until their DKIM is aligned to your domain.
Where to make the changes
At your DNS provider, which the check identifies from your nameservers. It's often not the same company you bought the domain from, and it's usually under a heading like "DNS", "Advanced DNS", or "Manage zone".
If you have no technical support
These are small changes, but they are DNS changes. If nobody at your organisation is comfortable making them, send this page to whoever set up your website or email. Adding a TXT record is a five-minute task for anyone who works with DNS.