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

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 is about safeguarding 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 big part of the company brand and most bussiness still rely strongly on email communication and website.

strongrecommendation

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

Use dedicated subdomains for vendors (e.g., @vendor.yourdomain.tld) and keep primary identities like ceo@yourdomain.tld protected. If you are not using the vendor remove the subdomain and thereby all permission to send email with your domain.

tipsTip: If a subdomain do not have SPF or DMARC policy, top domain policies will apply.

Step 1: Secure Every Domain

Step 2: Configure Your Email Gateway Correctly

Your email gateway is the first (or last) line of defense. It may run as a standalone product, 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

All three frameworks rely on public DNS TXT records. Each domain owner defines policies that receivers can check against. BUT, how effective they works depends on configurations in the email gateway. Both yours and anyone else on Internet sending or recieving email.

tipsTip: This will not go in to details about Mail Transfer Agent Strict Transport Security (MTA-STS), TLS Reporting (RFC 8460), or TLS-RPT for short, 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 source 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".
  • In this record multiple sources could be added. IP address, network (IPv4+IPv6),host, domain and also be based on “include” statements that could be blocks of host and network like of above.
  • There is limit of 50 resolves here. There is also services that allow you to have more than 50. My recommendation is to have as few as possible.

tipsTip: 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=

DKIM: Sign Your Emails

DKIM works by signing outgoing emails with a private key. Receivers then can 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 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 passed.

DKIM Signing

tipsTip: 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 Report

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

  • Policies:
    • none - Monitor only.
    • quarantine - Treat as suspicious
    • reject - Block
  • Reports:
    • rua Aggregate Report (Compressed, XML format). Include the validation results and action taken by reporting email gateway. Default collected by domain and sent to the email address every 24 hours.
    • ruf Failure/Forensic Report. Include more details. (could contains PII information). Reporting services offer PGP encryption of these reports to protect the information. Recommend to use a vendor within EU. Or only send them to internal mailbox.
    • fo=1This control the level of failure reporting. Using "1" is recommended,if SPF or DKIM do not pass. But it could also be set to "0" (default if not set), DMARC fail,"d" DKIM fail,"s" SPF failed. Or combined with fo=1:s.
    • ri Controls Report Frequency. If sending huge amount of email the default 24 hour report window may result in a to big RUA report. If so a RUF report will be sent to you to inform 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

tipsTip: I recommend that also domains that used for email communication has SPF + DMARC set up, spoofed emails with this domain will then fail validation and the recipent may be protected from an attack.

tipsTip: DMARC reports (rua) are sent in XML format, which is difficult to read manually. Use a DMARC report analyzer or trusted reporting service to visualize and understand 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 record for a domain NOT sending or receiving email:

Sample DNS records: 

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

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

If the domain do not have MX record anyone receiving email from your domain(s) should reject (if mail gateway are configured correctly) since the verification could NOT pass. This also help your organisation if the attacker try 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 actions based on the result. This means lower protection level and spoofed emails may still reach inboxes of the target, leaving users vulnerable to attacks like phishing and malware.

tipsTip: 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.

tipsTip: Hardenize Website https://www.hardenize.com give a good overview of the current status and is easy to use for troubleshooting.