Notes
Can someone send email pretending to be you?
Three records in your DNS decide the answer. Most business domains have two of them working and the one that actually stops an impersonation missing.
Email was designed without any way to prove who sent a message. The From line is typed by the sender, the way the return address on an envelope is written by whoever posted it. Nothing in the original design stops anybody putting your business address there.
Three records were added over the years to fix that, and they are published in your DNS, which means anybody can read yours right now including you. They are worth understanding because a convincing email from your address to your own customers is one of the cheaper attacks there is, and the damage lands on your name rather than on the attacker.
What the three records do
| Record | What it says | What it does on its own |
|---|---|---|
| SPF | These are the servers allowed to send mail for this domain | Gives the receiver a fact. Does not tell it what to do with a failure |
| DKIM | Genuine mail from this domain carries a signature matching this published key | Proves a message was not altered and came from an authorised sender. Again, no instruction |
| DMARC | When SPF and DKIM both fail, do this, and send me a report | The only one of the three that asks the receiver to reject anything |
That last column is the whole point. SPF and DKIM produce evidence. DMARC is the record that turns evidence into a decision, and without it a receiving mail server is left to guess, which usually means delivering the message.
The three words that decide everything
A DMARC record contains a policy, and it is one of three values. This single word is the difference between a domain that is protected and one that only looks protected.
- p=none. Monitor only. Failures are reported to you and delivered to the recipient anyway. This stops nothing. It exists so you can watch for a while before turning enforcement on, and it is where most domains that have DMARC at all have quietly stayed.
- p=quarantine. Failures go to the spam folder. This is real protection and it is the sensible destination for most businesses.
- p=reject. Failures are refused outright and never delivered. The strongest setting, and the one that punishes an incomplete inventory of your own senders hardest.
A domain publishing p=none has a DMARC record, will pass a checklist that asks whether DMARC exists, and offers no more protection against impersonation than a domain with no DMARC at all. If somebody tells you your email is protected, the question to ask is not whether DMARC is present. It is which of those three words is in it.
How to check yours
These are public records. You are not probing anything and you do not need permission or a login. On a Mac or Linux terminal, substituting your own domain:
- dig +short TXT yourdomain.com. Look for a line starting v=spf1. That is your SPF record. No such line means you have no SPF at all.
- dig +short TXT _dmarc.yourdomain.com. Look for a line starting v=DMARC1, then read the p= value in it. No line means no DMARC, which means no policy, which means nothing is being rejected.
- DKIM is checked differently, because its record sits at a selector name chosen by whoever set up your mail. Your mail provider will document theirs. Sending a message to an account you control elsewhere and viewing the raw headers is the practical check: genuine mail will carry a DKIM signature and a line reporting whether it passed.
If you would rather not use a terminal, any of the public DMARC and SPF lookup tools will read the same records, because there is only one copy and it is public.
Reading the SPF line
SPF records end in an instruction about everything not already listed. It is worth knowing which one yours ends with.
- -all is a hard fail. Anything not on the list is not from you.
- ~all is a soft fail. Suspicious, deliver anyway. Extremely common, and much weaker than it looks.
- +all means anyone may send as your domain. This is almost always a mistake and it undoes the entire record.
One other trap: SPF is evaluated with a limit on how many DNS lookups it may perform. A record that has accumulated an entry for every service you have ever tried can quietly exceed that limit, at which point it stops working correctly while still being present in your DNS and still looking fine to anybody who only checks that it exists.
Why almost everyone stops before the part that works
Because enforcement is where it gets frightening, and the fear is legitimate. Turning on quarantine or reject tells the world to throw away mail that fails, and if you have forgotten a sender, the mail it throws away is yours. Businesses send from more places than they remember: the mail provider, the website contact form, the invoicing system, the booking tool, the newsletter platform, the review request service, the payroll provider.
The order that avoids this is the reason p=none exists. Publish DMARC at p=none first, with a reporting address. Read the reports for a few weeks and they will tell you every source sending as your domain, including the ones nobody remembered. Authorise the legitimate ones. Then move to quarantine, and only then consider reject.
What this is actually protecting
Not your inbox. These records do nothing about the mail you receive. They protect your name in the inboxes of other people: your customers, your suppliers, your bank. The attack they prevent is a message that appears to come from you, asking somebody who trusts you to pay an invoice to a changed account, or to click something.
That is why this belongs on the same list as who holds your domain. Both are records nobody looks at until the day they matter, both are readable in minutes, and both are cheap to fix while nothing is wrong.
Questions
We have SPF. Are we protected?
Not by itself. SPF tells a receiving server which servers are allowed to send for your domain, but it does not tell that server what to do when the check fails, so the usual outcome is that the message is delivered anyway. DMARC is the record that supplies the instruction, and only when its policy is set to quarantine or reject.
We have DMARC. Is that enough?
It depends on one word in it. A DMARC record at p=none reports failures and delivers them anyway, which stops no impersonation at all, and that is where most domains with DMARC have stayed. Read the p= value. If it says none, you have monitoring rather than protection.
Could turning this on stop our own email working?
Yes, if it is done in the wrong order, and that risk is real rather than theoretical. Enforcement rejects mail from any sender you have not authorised, including your own forgotten ones. Publish at p=none first, read the reports until you have a complete list of everything sending as your domain, authorise those, and only then raise the policy.
How do I check this without a terminal?
Any public SPF or DMARC lookup tool will show you the same thing, because these are public DNS records with one published copy. There is nothing private to expose and no permission needed to read your own.
Does this stop spam and phishing reaching us?
No, and it is the most common misunderstanding about these records. They govern how the rest of the world treats mail claiming to be from your domain. Protecting what arrives in your own inboxes is a separate job handled by your mail provider filtering.