Email Deliverability
Find out why your mail lands in spam.
Email authentication is the single most common reason legitimate mail gets filtered. Three records do the work — SPF says which servers may send for your domain, DKIM signs each message so tampering is detectable, and DMARC tells receiving servers what to do when the first two fail.
Getting all three right is not difficult, but the failure modes are quiet. Mail keeps sending, nothing errors, and you only discover the problem when a customer says they never received the invoice. These tools read the records as a receiving mail server would.
Why legitimate mail lands in spam
Mail authentication answers one question for the receiving server: is this message really from the domain it claims? Three records answer it together, and a gap in any of them shifts you toward the spam folder even when nothing about the message is remotely suspicious.
That is the frustrating part. Nothing on your side looks broken. The mail sends, no error comes back, and the recipient simply never mentions it — because they never saw it.
The three records, in plain terms
SPF lists which servers may send mail using your domain. Without it, a receiving server has no way to distinguish your mail platform from anyone else who types your domain into a From field.
DKIM adds a cryptographic signature to each message, so the receiving server can verify it was not altered in transit and genuinely came from an authorised sender.
DMARC ties the two together and tells receivers what to do when a message fails: ignore it, quarantine it, or reject it outright. It also sends you reports on attempted spoofing, which is often the first sign someone is impersonating your domain.
All three are DNS records. None requires a change to your mail server, and none costs anything.
Reading the result honestly
A perfect score is not the goal. A domain that sends no mail at all is best served by an SPF record that authorises nothing and a DMARC policy of reject — that is a correct configuration and it will score well, because it accurately says "nothing legitimate sends from here".
What matters is whether the configuration matches what you actually do. The common failures are a domain sending through a platform that is missing from its own SPF record, a DMARC policy left at p=none for two years because nobody revisited it, and an SPF record that quietly exceeds the ten-lookup limit and therefore fails for everyone.
Before you change anything
Publishing a strict DMARC policy while a legitimate sending service is still missing from SPF will bounce your own invoices. The right order is: get SPF and DKIM correct for every service that sends on your behalf, run DMARC at p=none long enough to read the reports, and only then tighten to quarantine and reject.
That sequence takes a few weeks. Skipping it takes an afternoon and then breaks something you will not notice for days.
Common questions
I have SPF set up but mail still goes to spam. Why?
SPF alone is rarely enough now. Major providers expect DKIM signing as well, and a DMARC policy that ties them together. Content and sending reputation also matter: a new domain sending in volume looks suspicious regardless of how correct its records are.
Can I have two SPF records?
No, and this is a common cause of silent failure. A domain must publish exactly one SPF record. Two records is not treated as a broader rule — it is a permanent error, and receiving servers will fail the check entirely. Merge them into a single record with multiple include statements.
What is the SPF ten-lookup limit?
Each include, a, mx, ptr or exists mechanism in your SPF record costs a DNS lookup, and the total may not exceed ten. Chaining several mail platforms together blows through it easily. Past the limit the record does not degrade — it fails outright, exactly as if you had no SPF at all.
Should I set DMARC to reject straight away?
Not unless you are certain every legitimate sender is authenticated. Start at p=none, which changes nothing but sends you reports. Read them for a few weeks, fix whatever they reveal, then move to quarantine and finally reject. Starting at reject is how organisations discover their own billing system was never in SPF.
Do I need DKIM if I already have SPF?
Yes, in practice. SPF breaks when mail is forwarded, because the forwarding server is not in your SPF record. DKIM survives forwarding because the signature travels with the message. Between them they cover each other, which is why DMARC requires at least one to pass.
Does any of this stop people spoofing my domain?
It stops spoofed mail being delivered to anyone who checks — which today is every major mailbox provider. It cannot stop someone sending the message; it makes the message fail on arrival. A DMARC policy of reject is the closest thing available to preventing your domain being used in phishing.