What Are SPF, DKIM & DMARC

Why Care "Now"? — Because It Became Mandatory

Many organizations once treated SPF/DKIM/DMARC as "nice to have." Since 2024, the world's largest email providers have flipped that to "don't have it = won't deliver," especially for organizations that send high volumes — ERP notifications, invoices, newsletters, or marketing email.

The key point: the 5,000/day threshold doesn't mean small organizations are off the hook — even sending a few hundred a day, lacking DMARC lets attackers spoof your domain to deceive your customers, and your own legitimate email is more likely to land in spam.

What Is SPF? — "Who Is Allowed to Send for Me"

SPF (Sender Policy Framework) is a DNS TXT record listing which servers (IP addresses) are authorized to send email on behalf of your domain. When a receiving server gets a message, it checks whether the real sending IP is on the list your domain published. The standard is defined in RFC 7208.

An example SPF record that authorizes Google Workspace plus one organizational server IP to send:

example.com.   IN  TXT  "v=spf1 include:_spf.google.com ip4:203.0.113.25 -all"

The most important part is the closing tag, which decides how servers "not on the list" are handled:

• -all (Fail / strict) — servers not on the list are treated as "fail" → recommended for production
• ~all (SoftFail / lenient) — not-listed is "suspicious" but still accepted → good for early testing
• +all — allows every server → never use this, it's the same as having no SPF

SPF's weaknesses that DKIM and DMARC fill in: SPF only checks the "envelope" address (the Return-Path), not the From: domain the user actually sees, and SPF "breaks" when mail is forwarded because the sending IP changes. That's why SPF alone is not enough.

What Is DKIM? — "A Wax Seal Against Tampering"

DKIM (DomainKeys Identified Mail) applies a cryptographic signature to an email using public-key cryptography (RFC 6376) — the same concept as an electronic signature. The sending server uses a private key to sign the headers and body, embedding the signature in a header, while the receiver fetches the public key from the domain's DNS record to verify it.

If it passes, two things are simultaneously true: (1) the email truly came from the claimed domain, and (2) the content was not altered in transit. An example DKIM-Signature header and the public-key DNS record:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
  h=from:to:subject:date; bh=...; b=...

selector1._domainkey.example.com.  IN  TXT
  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ..."

The word selector1 is the "selector" — it lets one domain hold several keys (e.g. separate keys for the ERP, the newsletter platform, and Google Workspace) and rotate keys independently. A key advantage: DKIM survives forwarding, because the signature travels with the email and isn't tied to the sending IP.

What Is DMARC? — "The Policy and Reporting That Ties It All Together"

DMARC (Domain-based Message Authentication, Reporting & Conformance) is the policy layer that sits on top of SPF and DKIM (RFC 7489). It does three things:

• Alignment — requires the From: domain the user sees to match the domain that passed SPF or DKIM. This is the core that closes the loophole SPF/DKIM leave open alone.
• Policy — tells receivers what to do with mail that fails.
• Reporting — has receivers send aggregate reports back so the domain owner can see who is sending mail in their name.

An example DMARC record setting the strictest policy (reject) with reporting enabled:

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

The p= value is the policy level, which you should ramp up gradually so legitimate mail isn't blocked by accident:

The adkim=s and aspf=s set strict alignment that must match exactly, whereas the default r (relaxed) accepts a match at the organizational-domain level (e.g. mail.example.com counts as matching example.com). Most organizations start with relaxed.

SPF vs DKIM vs DMARC in One Table

The three are not "alternatives" — they are a "team that must work together." A summary of each one's role:

Why This Matters for ERP Organizations

Modern ERP systems send email "on your behalf" constantly — quotations, invoices, purchase orders, electronic tax invoices, and approval notifications. Because this email "is about money," it becomes a direct target for fraudsters.

The most dangerous case is Business Email Compromise (BEC) — an attacker spoofs email in your company's name to your customers, attaching an "invoice" that looks exactly real but with a changed destination account number. If your domain lacks a DMARC reject policy, the customer has no way to know the email is fake. This is the same mechanism explained in our article on accounts payable and invoice-fraud prevention.

To be fully honest: SPF/DKIM/DMARC are configured at the domain and mail-server level of the organization, not a feature inside the ERP software itself. What the Grand Linux team can do is configure the ERP to send through an SMTP relay that signs DKIM correctly, and advise on placing matching SPF/DKIM/DMARC records on your domain's DNS — so that email leaving the ERP passes all three checks.

How to Roll It Out Correctly (Without Breaking Your Own Mail)

1. First map who sends mail in your domain's name — ERP, staff email (Google Workspace / Microsoft 365), newsletter platform, CRM, and so on. Make a complete list.
2. Build SPF to cover every source — add each provider's include:, watching the 10 DNS-lookup ceiling.
3. Enable DKIM on every system that supports it — each system usually generates a selector + public key for you to publish in DNS.
4. Start DMARC at p=none — to collect reports (rua) and see which sources don't yet pass alignment.
5. Move up to quarantine, then reject — only once the reports are stable and 100% of legitimate mail passes do you tighten the policy.
6. Review reports regularly — the DMARC report is your radar showing whether anyone is trying to spoof your domain.

Summary: Which Organization Should Do What

Your email domain is your brand's digital signature — leaving SPF, DKIM and DMARC unset is like signing blank cheques for anyone to pick up and fill in. The work takes a few hours, but it protects a level of trust you cannot put a price on.

- The Saeree ERP Team

References

• RFC 7208 — Sender Policy Framework (SPF): datatracker.ietf.org/doc/html/rfc7208
• RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures: datatracker.ietf.org/doc/html/rfc6376
• RFC 7489 — Domain-based Message Authentication, Reporting & Conformance (DMARC): datatracker.ietf.org/doc/html/rfc7489
• Google — Email sender guidelines (bulk senders, Feb 2024): support.google.com/mail/answer/81126
• Yahoo — Sender Best Practices: senders.yahooinc.com/best-practices
• Microsoft — Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders (May 2025): techcommunity.microsoft.com