DMARC, SPF and DKIM: Stop Domain Spoofing Before It Starts

The fake invoice did not come from a strange domain. It came from the company’s own domain, used the CEO’s display name, copied the normal email signature, and landed in the finance inbox at the end of the month. Nobody had to compromise the CEO’s mailbox. The attacker simply spoofed the sender because the domain had no meaningful email authentication policy.

SPF, DKIM, and DMARC are not glamorous controls, but they are some of the highest-return security work a small business can do. They tell receiving mail systems which servers are allowed to send for your domain, whether the message was signed by an authorized domain, and what to do when authentication fails.

The Short Version

SPF lists the servers allowed to send mail for a domain. DKIM signs messages so receivers can verify that the message was authorized by the domain and was not modified in transit. DMARC ties SPF and DKIM to the visible From domain and publishes a policy: monitor, quarantine, or reject mail that fails alignment.

SPF  = "Who is allowed to send for this domain?"
DKIM = "Was this message signed by a trusted domain?"
DMARC = "Does the visible From domain align, and what should receivers do if it fails?"

Google’s sender guidelines require SPF or DKIM for all senders to Gmail and require SPF, DKIM, and DMARC for bulk senders. Even if you do not send bulk mail, the same controls reduce impersonation risk and improve deliverability.

Step 1: Inventory Every Sender

Before touching DNS, list every service that sends email as your domain. This usually includes Google Workspace or Microsoft 365, your website contact form, CRM, marketing platform, ticketing system, accounting software, and any application that sends password resets or invoices.

Sender inventory example:
- Google Workspace: employees@example.com
- WordPress SMTP plugin: contact forms
- Stripe: receipts
- HubSpot: marketing email
- Zendesk: support replies
- GitHub: security notifications
- Custom app: password reset messages

If a sender is not in the inventory, it will break when you enforce DMARC. That is why good DMARC projects begin with monitoring rather than immediate rejection.

Step 2: Publish A Correct SPF Record

SPF is a DNS TXT record on the sending domain. It should include only services that are authorized to send mail. A common mistake is adding every vendor forever until the record becomes too long or includes abandoned platforms.

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

Use one SPF record per domain. Multiple SPF TXT records cause evaluation problems. If a vendor says to add a second SPF record, merge it into the existing one. Prefer a strict ending such as -all once you are confident. During early testing, some teams use ~all, but do not leave weak policy forever without a reason.

Step 3: Turn On DKIM Everywhere

DKIM is usually configured inside each email platform. The platform gives you a DNS record, often a TXT or CNAME record, under a selector such as google._domainkey.example.com or selector1._domainkey.example.com. Once published, the platform signs outgoing mail.

google._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
selector1._domainkey.example.com. CNAME selector1-example-com._domainkey.vendor.example.

Use 2048-bit DKIM keys when your provider supports them. Rotate keys when employees leave platforms, when a vendor is removed, or when the vendor recommends rotation. DKIM is the part that often saves DMARC alignment when SPF fails because of forwarding.

Step 4: Start DMARC In Monitor Mode

DMARC lives at _dmarc.example.com. Start with p=none and aggregate reporting. This does not block spoofed mail yet, but it tells you who is sending mail using your domain and whether messages pass alignment.

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s; pct=100"

Do not send raw DMARC XML reports into a normal inbox forever. Use a DMARC reporting tool or parse them into a dedicated mailbox. You are looking for legitimate senders that fail alignment and suspicious sources that should never be sending as your domain.

Step 5: Move To Quarantine, Then Reject

Once legitimate senders pass SPF or DKIM alignment, move from monitor mode to enforcement. A staged approach lowers the risk of breaking real mail.

Week 1-2: p=none; collect reports
Week 3:   p=quarantine; pct=25
Week 4:   p=quarantine; pct=100
Week 5:   p=reject; pct=25
Week 6:   p=reject; pct=100

The destination is p=reject. A domain stuck on p=none has visibility, not protection. For inactive domains that never send mail, publish SPF and DMARC records that reject everything.

unused-domain.example. TXT "v=spf1 -all"
_dmarc.unused-domain.example. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Common Mistakes

The most common mistake is confusing authentication with alignment. A message can pass SPF for a vendor’s bounce domain but still fail DMARC because the visible From domain does not align. Another mistake is forgetting subdomains. If support mail comes from support.example.com, give that subdomain its own policy or use sp=reject carefully from the organizational domain.

Also watch SPF lookup limits. SPF evaluation has a DNS lookup limit, and too many nested includes can cause failures. If your record is bloated, remove abandoned services before adding new ones.