Email Security Frameworks: Why SPF, DKIM, and DMARC Matter

Last updated

Over the past few years, I’ve helped multiple companies strengthen their email security — both before and after breaches.

One thing is clear: default configurations are not enough. Attackers exploit weak setups every day. Protecting your email domain safeguards both your brand and the people who trust your messages.

This post summarizes key learnings and practical steps you can take to protect your domain, your users, and others on the internet. Your domain is a critical part of your company brand, and most businesses still rely heavily on email communication and websites.

Strong recommendation

Keeping your top domain as clean as possible is highly recommended. Letting third-party vendors send from your main domain is risky. If their systems are compromised, attackers can impersonate your brand while still passing SPF, DKIM, and DMARC checks.

Use dedicated subdomains for vendors (for example @vendor.yourdomain.tld) and keep primary identities like ceo@yourdomain.tld protected.

If you stop using a vendor, remove the subdomain and revoke their ability to send email from your domain.

Tip: if a subdomain does not have its own SPF or DMARC policy, the policy from the top domain will apply.

Step 1: Secure every domain

  • Apply SPF and DMARC policies to all domains you own. Even if a domain doesn’t send or receive email, it can still be abused for spoofing. Protect it anyway.
  • Configure validation for incoming email. Many organizations publish SPF/DKIM/DMARC records for their domains but forget to enforce these checks on their own inbound email service.

    Example: if you receive email from my domain nansec.se and it fails validation, my policy is to reject it. But that action depends on your system configuration, and the default may not be to enforce the policy set for the domain. This makes you and your organization less secure and more likely to be successfully targeted by various attacks via email.

Step 2: Configure your email gateway correctly

Your email gateway is the first (or last) line of defence. It may run as a standalone product, as part of a multifunction gateway, or as a SaaS solution. Most vendors provide common features, but the default settings are rarely the most secure. To achieve real protection, you need to configure protocol-level frameworks correctly.

When SPF, DKIM, and DMARC are enforced, your domain gains trust across the internet. Recipients know your email is authentic, phishing attempts are reduced, and your brand reputation is protected.

Step 3: Implement SPF, DKIM, and DMARC

  • SPF (Sender Policy Framework) – RFC 7208
  • DKIM (DomainKeys Identified Mail) – RFC 6376
  • DMARC (Domain-based Message Authentication, Reporting, and Conformance) – RFC 7489

All three frameworks rely on public DNS TXT records. Each domain owner defines policies that receivers can check against. But how effective they are depends on the configuration in the email gateway — both yours and that of anyone else on the internet sending or receiving email.

Tip: this guide does not go into detail on Mail Transfer Agent Strict Transport Security (MTA-STS), TLS Reporting (TLS-RPT, RFC 8460), DNS-based Authentication of Named Entities (DANE), or Brand Indicators for Message Identification (BIMI).

SPF: define who is allowed to send with your domain(s)

SPF specifies which sources are allowed to send mail on behalf of your domain.

Example SPF DNS record (Exchange Online):

"v=spf1 include:spf.protection.outlook.com -all"
  • The -all means only servers in the include list are trusted.
  • Some recommend ~all (soft fail), but the goal should be -all.
  • Multiple sources can be added to this record: IP address, network (IPv4 and IPv6), host, domain, and include statements that reference further blocks of hosts and networks.
  • There is a limit of 10 DNS lookups. Some services let you work around it — my recommendation is to keep as few as possible.

Tip: start with a softer policy if you’re just implementing SPF, but make a plan to move to -all.

Sample email header:

Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=40.107.130.140; helo=mrwpr03cu001.outbound.protection.outlook.com; envelope-from=niklas.andersson@nansec.se; receiver=<UNKNOWN>

DKIM: sign your emails

DKIM works by signing outgoing emails with a private key. Receivers can then verify the signature using your published public key in DNS.

  • Ensures message integrity (content hasn’t been altered).
  • Uses selectors so multiple keys can exist.

Example DKIM DNS record (Exchange Online):

"selector2._domainkey.nansec.se. CNAME selector2-nansec-se._domainkey.nansec.onmicrosoft.com."

Clarification (hopefully not a rabbit hole):

  • DKIM does not encrypt email content. Instead, it signs it.
  • A checksum (hash) of selected email headers and the body is created.
  • That checksum is encrypted with the sender’s private key and placed in the DKIM-Signature header.
  • The receiving mail server recomputes the checksum and retrieves the sender’s public key from DNS.
  • It uses the public key to decrypt the signature and compare the result with its own checksum.
  • If they match, the message is verified and DKIM has passed.
Diagram of the DKIM signing and verification process

Tip: DKIM can run in relaxed or strict mode. Strict alignment improves security but requires tighter domain matching.

Sample email header:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nansec.se;
s=selector2;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=WR8udjOj+KLb6y8QUNiZevZl4y25GIh6jNpcp4OWl0U=;
b=uD2Ohu9sxjUBj8hCp1+6nbJ593aZrmrcnSfhwM9tSh+EeSie8p7L+8Utjhov78AMCSkb3uDDO11mzv9hIux2dAWcr4TN6tYi+Mz63yxKAYhZX5YVUpxGpy7Xd6ylf0B6C3Jt95JZvdkVYHAiDbMvMTtULW6QbtxFCSDX6aOSATtFVQewiWMMLZ0MCv4IIqN5aRa257vLVu+E7XSDamSzTshDRoswWEOJvhoGqOKvDAV3yKBvvRgcEudQFcomVDNGASY9Em2HztqSRZjnLbK48eKxLHE7j+Pmb+6LyFCS6ItvA+XDqzpZ/ZOZqrEqSZvaQCwg3EA69Exmtr/AHOx0CA==

DMARC: policy and reporting

DMARC ties SPF and DKIM together. It requires that at least one passes and aligns with the policy set for the “From” domain.

  • Policies:
    • none – monitor only.
    • quarantine – treat as suspicious.
    • reject – block.
  • Reports:
    • rua – aggregate report (compressed XML). Includes the validation results and the action taken by the reporting email gateway. Collected per domain and sent to the given email address every 24 hours by default.
    • ruf – failure/forensic report. Includes more detail (may contain PII). Reporting services offer PGP encryption of these reports to protect the information. I recommend using a vendor within the EU, or only sending them to an internal mailbox.
    • fo=1 – controls the level of failure reporting. Using 1 is recommended: it reports if SPF or DKIM do not pass. It can also be set to 0 (the default if not set) for DMARC failure, d for DKIM failure, or s for SPF failure — and combined, as in fo=1:s.
    • ri – controls report frequency. If you send a large amount of email, the default 24-hour report window may produce a RUA report that is too big. If so, a RUF report will be sent to inform you that the RUA collection failed.
  • Recommendation:
    • Start with p=none (collect reports).
    • Move to p=quarantine.
    • Finally, set p=reject.

Sample DMARC DNS record:

_dmarc.nansec.se. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-rua@nansec.se; ruf=mailto:dmarc-ruf@nansec.se; fo=1;"

Sample email header:

Authentication-Results: emailgateway.domain.tld;
  dkim=pass (2048-bit key; unprotected) header.d=nansec.se header.i=@nansec.se header.a=rsa-sha256 header.s=selector2 header.b=uD2Ohu9s;
  dkim-atps=neutral

Tip: I recommend that domains not used for email communication also have SPF and DMARC set up. Spoofed emails using those domains will then fail validation, and the recipient may be protected from an attack.

Tip: DMARC aggregate reports (rua) are sent in XML, which is difficult to read manually. Use a DMARC report analyzer or a trusted reporting service to visualize who is sending email on your behalf. This makes it easier to spot misconfigurations or abuse — and will get you to a reject policy faster.

Sample SPF and DMARC records for a domain not sending or receiving email:

# SPF record
nansec.se. TXT "v=spf1 -all"

# DMARC record
_dmarc.nansec.se. TXT "v=DMARC1; p=reject;"

If the domain has no MX record, anyone receiving email from it should reject the message (assuming their mail gateway is configured correctly), since verification cannot pass. This also helps your organisation if an attacker tries to spoof your domain to build trust in an attack against you.

Common pitfall: validation without enforcement

Most gateways verify SPF/DKIM/DMARC by default, but are not configured to take action based on the result. This means a lower protection level: spoofed emails may still reach the inboxes of the target, leaving users vulnerable to attacks like phishing and malware.

Tip: always configure your gateway to follow the domain owner’s published policies. That helps keep your organisation more secure.

Final thoughts

As a domain owner, your responsibility goes beyond protecting your brand — you’re also helping to stop attackers from abusing your domain to trick others. SPF, DKIM, and DMARC are no longer optional; they are a very important part of modern email security.

Don’t wait until a phishing incident damages your reputation or compromises your customers.

Start today:

  • Step 1: enable SPF, DKIM, and DMARC on every domain you own.
  • Step 2: monitor reports to understand who is sending on your behalf.
  • Step 3: gradually tighten policies from “none” → “quarantine” → “reject”.

Every step you take raises the cost for attackers and builds trust in your email. Small tweaks to default configurations can deliver a big leap in protection when combined with these frameworks.

Take action now. Protect your domain, protect your users, and protect your brand.

Tip: Hardenize gives a good overview of your current status and is easy to use for troubleshooting.

Want help getting to p=reject safely?

We implement and verify email security frameworks without breaking legitimate mail flow.

Book an assessment