SPF, DKIM and DMARC: Stop People Sending Mail as Your Domain

The phone call nobody wants

A customer rings: "We paid into your new bank account like your email said, so why are you still chasing us?" The email showed [email protected], with your logo and signature, but you never sent it. This kind of fraud (business email compromise) is easy because email (SMTP) was designed without any check on who the sender is. Anyone can put your domain in the From line, unless your domain tells the world otherwise. SPF, DKIM and DMARC are how it does that.

The second reason is getting your mail delivered at all. Since 2024, Gmail and Yahoo have required bulk senders (over 5,000 messages a day) to have all three, and every sender to have at least SPF or DKIM. Microsoft applied similar requirements to Outlook.com from May 2025, and from late 2025 Gmail moved from warnings to actually rejecting non-compliant bulk mail. Even if your company sends far less than that, domains without these records are more likely to land in spam.

Three records, one sentence each

• SPF: the list of servers allowed to send mail for this domain.
• DKIM: a digital signature on every message proving this domain sent it and the content wasn't changed.
• DMARC: tells receivers what to do with mail that claims to be from you but fails, and sends you reports.

Before you start: who holds your DNS?

In Laos the first obstacle we hit is usually not technical. Nobody knows where the DNS for the .la or .com domain is hosted, or who has the login. Often it sits with a web design company hired years ago. Find out which provider hosts your DNS, move the account into the company's name and turn on MFA. Whoever can edit your DNS controls all of your email.

SPF

A TXT record on the root domain (yourcompany.la). For Microsoft 365:

v=spf1 include:spf.protection.outlook.com -all

For Google Workspace use include:_spf.google.com instead. Any other system that sends as your domain (ERP, newsletter platform, website, a scanner relaying through the ISP's SMTP) must be added too.

The two rules that break SPF most often:

• One SPF record per domain. Two records make SPF fail entirely (permerror). We see this a lot after a web host adds its own record instead of merging with the existing one.
• No more than 10 DNS lookups. Every include, a and mx counts, including nested includes. A single include can use several lookups, so run an SPF checker every time you change the record.

-all (hard fail) or ~all (soft fail)? Once DMARC is enforcing, DMARC decides the outcome, so many administrators use ~all to stop some servers rejecting forwarded mail before DKIM is checked. Either is acceptable; what matters is that the list of senders is complete.

DKIM

The sending server signs each message with a private key; the public key sits in DNS at <selector>._domainkey.yourcompany.la. DKIM survives forwarding better than SPF because the signature travels with the message.

• Microsoft 365: enable it in the Defender portal (Email authentication settings) and add the two CNAME records selector1._domainkey and selector2._domainkey with the values the portal shows. Always copy the values from the portal rather than typing them.
• Google Workspace: generate a 2048-bit key in the Admin console, add the TXT record at google._domainkey, then click Start authentication.
• Other platforms (newsletters, CRM) usually have their own DKIM setup. Turn it on for each, and make it sign with your domain, not the provider's.

Note: some DNS providers limit each TXT string to 255 characters. A 2048-bit key is longer and must be split into multiple strings. If DKIM fails after you add the record, check this first.

DMARC

A TXT record at _dmarc.yourcompany.la. Start with:

v=DMARC1; p=none; rua=mailto:[email protected]

When you're ready, it becomes:

v=DMARC1; p=reject; rua=mailto:[email protected]

A message passes DMARC when SPF or DKIM passes and the domain that passed aligns with the From domain the user sees. That's why a newsletter platform sending through its own domain will fail DMARC until you set up DKIM with your domain.

rua reports arrive as XML files that are hard to read by eye. Use a DMARC analysis tool (free and paid ones exist) to see which IPs send as you and whether they pass. If reports go to a different domain, such as your analysis provider's, that domain must publish a record agreeing to receive reports for you. Good services set this up themselves.

What changed in the 2026 standard

In May 2026 the IETF published the revised DMARC standard (DMARCbis, RFC 9989). What matters day to day:

• The pct tag is gone, because receivers applied it inconsistently. It is replaced by t=y (testing mode: don't apply the policy). Ramping up through pct=25 and pct=50 is no longer the recommended path.
• A new np tag sets the policy for subdomains that don't exist, a favourite trick of spoofers (billing.yourcompany.la, for example).
• Existing records keep working. Retired tags are simply ignored; they don't break the record.

Worked example: a 60-person company with four sending systems

The final SPF record has one include, the newsletter passes DMARC through DKIM, and the reputation of the main domain no longer depends on marketing campaigns. Moving newsletters to a subdomain is something we recommend almost every time: if one campaign draws a lot of spam complaints, your invoices still arrive.

A 6–8 week plan

Week 1. List every system that sends as your domain. Ask finance, marketing and HR, not just IT. Turn on DKIM and complete SPF.

Weeks 1–4. Publish DMARC p=none with rua. Read the reports weekly. You'll find systems everyone forgot, and you may find someone already spoofing your domain.

Weeks 4–6. Once all legitimate systems pass, move to p=quarantine. If you have several subdomains, enforce them one at a time rather than relying on pct.

Weeks 6–8. Move to p=reject, and keep reading reports. A new system bought by another department will show up in the reports before anyone tells IT.

Domains that never send mail (spare domains, old company names): publish v=spf1 -all and v=DMARC1; p=reject; straight away.

To check: send a message to a Gmail account, open "Show original", and confirm SPF, DKIM and DMARC all show PASS.

What we keep finding

• Two SPF records after a website hosting move.
• p=none left in place for two years with nobody reading reports. It protects nothing.
• A jump to p=reject in one day, after which ERP invoice emails stop reaching customers.
• Some mailboxes still on old hosting and the rest on Microsoft 365, with SPF covering only one side.
• The belief that DMARC stops look-alike domains such as yourc0mpany.la or yourcompany-la.com. It doesn't. That takes email filtering and phishing awareness training for staff.

Beyond DNS

SPF, DKIM and DMARC stop people spoofing your domain. They don't inspect the content of incoming mail. For that:

For payments, the best rule isn't technical at all: any change of bank account must be confirmed by phone, using a number already on file, never the number in the email.

Once DMARC is at quarantine or reject, you can look at BIMI to show your logo in supporting inboxes; Gmail also requires a logo certificate (VMC or CMC).

If staff still use free personal accounts (Gmail or Yahoo) for company business, the first step is business email on your own domain. You can't set DMARC for gmail.com.

Send us your domain name

The domain name is all we need, since these records are public. We'll check your existing SPF, DKIM and DMARC and send back corrected records you can paste straight into DNS.