Get started
DNS records
Four records decide whether your mail is accepted, and each one answers a different question a receiving server asks. Worth understanding rather than pasting, because when one fails the error only makes sense if you know what it was for.
SPF — may this server send for you?
example.com. 3600 IN TXT "v=spf1 include:mail.scanmypass.com ~all"A receiving server takes the domain in the envelope sender, looks up its SPF record, and checks whether the IP that just connected is authorised. The include: hands that decision to us, which means we can add or change sending IPs without you touching your DNS again.
One SPF record per domain. Exactly one.
Two records starting v=spf1 is a permanent error — receivers do not pick one, they fail the check entirely. If you already have SPF because of Google Workspace or another service, add our include: to the existing record instead:
"v=spf1 include:_spf.google.com include:mail.scanmypass.com ~all"What ~all and -all mean
~all is a soft fail: mail from an unauthorised IP is suspicious but not rejected outright. -all is a hard fail. Start with ~all — a hard fail while you still have a forgotten service sending as your domain will silently break that mail.
DKIM — was the message altered in transit?
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq…"Every message is signed with a 2048-bit key generated for your domain alone. The receiver fetches the public half from this record and verifies the signature, which proves both that you authorised the message and that nothing changed on the way.
The private half never leaves our database unencrypted and is decrypted only in memory at the moment of signing. It is not shown to you, and it is not shared with any other account.
This is a long value
The record is around 400 characters. Some DNS interfaces split long TXT values into 255-character chunks automatically, which is correct and fine. Some require you to do it. If verification reports a key mismatch, the usual cause is a value that was truncated on paste — copy it again from the dashboard rather than retyping it.
DMARC — what should happen when a check fails?
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"SPF and DKIM report a result. DMARC is where you say what to do about it, and it is the record that stops someone else sending mail that claims to be from you.
| Policy | What receivers do | When to use it |
|---|---|---|
| p=none | Nothing. Failures are reported to you but still delivered. | Start here, for a week or two. |
| p=quarantine | Failing mail goes to spam. | Once your own mail passes consistently. |
| p=reject | Failing mail is refused outright. | When you are confident nothing legitimate fails. |
Add rua= from the start. Without it you get no aggregate reports, which means no way to discover the forgotten service that will break when you tighten the policy.
Return path — whose domain do bounces come back to?
bounce.example.com. 3600 IN CNAME bounce.scanmypass.com.Optional, and worth doing. Without it, mail leaves with an envelope sender at our domain, so a recipient sees “mailed-by” pointing at us rather than at you.
With it, the envelope sender is at your own domain — which also puts SPF in DMARC alignment, so DMARC passes on SPF and DKIM rather than on DKIM alone. That is a stronger result than most senders manage.
The label defaults to bounce and is yours to change. If another service already uses that name on your domain — some use send, some em — pick a free one on the Domains page and publish that instead.
When verification fails
Every failure names the specific problem rather than just refusing. These are the ones that come up.
| What it says | What actually happened |
|---|---|
| MISSING_RECORD | Nothing at that name. Usually the record went on the wrong label — check for bounce.example.com.example.com, which is what typing the full hostname into a relative name field produces. |
| MULTIPLE_SPF_RECORDS | Two records starting v=spf1. Merge them into one. |
| INCLUDE_MISSING | An SPF record exists but does not authorise us. Add the include: to it. |
| KEY_MISMATCH | A DKIM record exists but its key is not the one issued for this domain — usually a truncated paste, or a record left behind by a previous provider. |
| LOOKUP_FAILED | Your nameservers did not answer. Transient — wait a minute and re-check. It is not a problem with the record itself. |
How long propagation takes
Verification asks your domain's own nameservers, so it sees a change as soon as your provider has actually made it — usually under a minute. What takes longer is the rest of the internet: other resolvers keep the old answer until its TTL expires, which is why a record can verify here and still not be visible everywhere for an hour.