SPF, DKIM and DMARC explained: who can send email in your name

A customer gets an email from your business address. The logo is right, the signature is right, and there is an invoice attached. The only thing that differs is the bank account number. The customer pays, and you find out two weeks later when they ask why you have sent a payment reminder for something they already settled.

Putting someone else's address in the "From" field is technically trivial. Email was designed at a time when nobody expected people to pretend to be someone else. The safeguards with the short names SPF, DKIM and DMARC were added later, so that mail servers could check whether a message really came from you. They only work, though, once someone sets them up on your domain.

The three safeguards in plain words

All three are entries in your domain's DNS, the same place where someone sets which server your website points to. Nothing gets installed on anyone's computer.

SPF is a guest list. It says: email from my domain may be sent by these servers and no others. The list should include your business email, your invoicing software, your newsletter tool and anything else that sends mail using your address. An entry looks roughly like this: v=spf1 include:_spf.google.com ~all.

DKIM is a seal. Your mail server signs every outgoing message, and the key for checking that signature sits in DNS. That lets the recipient confirm the message came from you and that nobody changed it on the way.

DMARC is an instruction for the recipient. It says what to do with a message that claims to be from you but fails the checks. It also checks something SPF alone does not: whether the domain confirmed by SPF or DKIM matches the address the customer actually sees in the "From" field. Without that, a fraudster can pass SPF with their own domain and still show yours on screen. DMARC can also ask receiving servers to send you reports, so you learn who is sending email in your name. The entry lives at _dmarc.yourdomain.com.

There is a second reason to deal with this. Since 2024 Gmail and Yahoo, and since 2025 Microsoft for Outlook.com mailboxes, have required bulk senders to have working SPF, DKIM and at least a basic DMARC record. So missing records hurt your genuine email as well.

How to check whether your domain has them

There are two easy ways, and neither needs access to your domain settings.

The first is a free DNS lookup tool, such as our SPF, DKIM and DMARC check. Enter your domain, without www and without https://. For DMARC you will see one of three things:

• no record, which means no protection,
• a record with p=none, which watches but blocks nothing,
• a record with p=quarantine or p=reject, where forged messages go to spam or get turned away.

For SPF, the main thing to check is that there is exactly one record. Two separate SPF records on the same domain is an error that can make receiving servers treat your SPF as invalid.

The second way is Gmail. Send an email from your business address to any Gmail account, open it, click the three dots next to the reply button and choose Show original. At the top you will see separate lines for SPF, DKIM and DMARC, each saying PASS or FAIL. Three passes is a good sign. Repeat the test with an invoice from your accounts software and a message from your website's contact form, because each of them leaves by a different route.

From p=none to quarantine without losing your own email

The most common mistake is jumping straight to p=reject. Then it turns out that invoices from the accounts software, shop notifications or the newsletter never had proper SPF or DKIM. From that moment they land in spam or do not arrive at all, and it takes a long time to work out why.

A safer order looks like this:

1. Set DMARC to p=none with an address for reports, for example v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com.
2. Collect reports for a few weeks. They arrive as XML files, so the easiest thing is to feed them into one of the free DMARC report readers, which turns them into a readable table.
3. List every service that, according to the reports, sends email as your domain. For each one that is genuinely yours, set up SPF and DKIM properly.
4. Once the reports show only sources you do not recognise, move to p=quarantine. Forged messages will start going to spam.
5. After a few more quiet weeks you can move to p=reject, where receiving servers refuse forgeries outright.

If you own domains that never send email, such as an old company name or a domain bought just in case, give them v=spf1 -all and a DMARC record with p=reject straight away. You lose nothing, and a fraudster cannot use them instead of your main one.

What these records will not do

DMARC protects your exact domain. It will not stop someone who registers a lookalike, such as your-domain.com or yourdomain.co, and sets up perfectly valid records of their own. Nor will it help if someone takes over a real staff mailbox, because then the fake emails leave from your own server and pass every check.

So alongside the DNS records, two simple things help. First, two-factor login on every mailbox in the business. Second, a rule your customers know: bank details never change by email, and any notice of a new account is confirmed through another channel. You can say so plainly on your invoices or in your email signature.

What to ask whoever manages your domain

Your domain is usually handled by your hosting company, the company you bought it from, or your developer. Send them these questions:

1. Which services send email from our domain, and are they all in the SPF record?
2. Do we have exactly one SPF record, and does it stay within the limit of ten DNS lookups?
3. Is DKIM switched on for our business email, our invoicing software and our newsletter tool? In Microsoft 365 and Google Workspace it usually has to be switched on by hand.
4. Do we have DMARC, at what level, and who reads the reports?
5. When can we safely move to p=quarantine?

A good answer does not need to be long. What matters is that it names a person who looks at the reports from time to time, and a date for moving to the next level of protection.