Email Security Beyond Spam Filters: What DMARC, DKIM, and SPF Actually Do

Email spoofing attacks, where a message is crafted to appear as if it came from a trusted domain, rely on gaps in authentication at the sending and receiving ends. The three standards that address this, SPF, DKIM, and DMARC, have been available for years and are widely recognised as baseline controls. Despite this, the majority of organisations we audit have these standards partially configured, misconfigured, or configured at a level that does not provide meaningful protection. They have SPF records that include too many sending sources, DKIM keys that are not rotated, and DMARC policies set to monitoring mode that have not moved to enforcement in two years.

This article explains what each standard actually does, how the three work together, and where the common gaps sit. Understanding the mechanics is important because these are not controls you can set and forget. They require maintenance as your email sending infrastructure changes, and they only provide protection when they are configured to enforce, not just to report.

SPF: Defining Who Can Send on Your Behalf

Sender Policy Framework lets you publish a list of authorised sending sources for your domain in DNS. When a receiving mail server gets a message claiming to be from your domain, it checks the SPF record to see whether the sending IP address is on the authorised list. If it is not, the receiving server can reject the message, mark it as suspicious, or let it through depending on the receiving server's policy and your SPF record's configured response.

The common failure with SPF is incomplete or over-broad records. Many organisations add every sending service they use over time without removing old entries, ending up with a record that either includes too many sources to be useful or hits the DNS lookup limit that breaks SPF evaluation entirely. The other frequent problem is that SPF can be bypassed by spoofing the display name or the header "From" address rather than the envelope sender, which is the address SPF evaluates. SPF alone does not protect what the recipient sees as the sender's address.

DKIM: Signing Messages to Verify They Were Not Tampered With

DomainKeys Identified Mail adds a cryptographic signature to outbound messages. The signature is generated using a private key held by the sending mail server and can be verified by the receiving server using the corresponding public key published in your DNS. A valid DKIM signature confirms that the message came from a server authorised to sign for the domain and that the message content was not modified in transit.

DKIM is more resistant to certain spoofing techniques than SPF, and unlike SPF it survives mail forwarding in most cases. The gaps in DKIM implementations are usually around key management: organisations deploy DKIM and then leave the keys unchanged indefinitely. A rotated, well-managed DKIM key that is unique per sending service provides meaningful assurance. A single key that has been in place for five years and is shared across all sending services provides much less. DKIM also needs to be configured for every legitimate sending service that sends on behalf of your domain, not just your primary mail platform.

DMARC: Tying Authentication to a Policy

Domain-based Message Authentication, Reporting and Conformance is the policy layer that sits above SPF and DKIM. It tells receiving mail servers what to do when a message fails authentication checks and where to send reports about authentication results. Without DMARC, a message that fails SPF and DKIM may still be delivered, depending on the receiving server's local policy. With DMARC, the sending domain's owner specifies the intended behaviour.

DMARC policies can be set to none (report only, take no action), quarantine (send failing messages to the spam folder), or reject (block failing messages entirely). The protective value only comes with quarantine or reject. Organisations that deployed DMARC at "none" to monitor their sending sources and then never progressed to enforcement have reporting data and no protection. Moving to enforcement requires confidence that all legitimate sending sources are covered by SPF and DKIM, which is why the monitoring phase exists, but monitoring is not the destination.

Where the Gaps Usually Are

In practice, the most common gaps we find are:

• DMARC policy set to "none" with no plan or timeline to move to quarantine or reject
• Third-party services sending email on the organisation's behalf that are not covered by SPF or DKIM
• SPF records with too many DNS lookups, causing lookup failures that break SPF evaluation
• DKIM not configured for marketing platforms, customer communication tools, or automated notification systems
• DMARC reports not being reviewed, so the organisation does not know about legitimate sending sources that are failing authentication
• Subdomains without DMARC records, which can be spoofed even when the primary domain is protected

Each of these gaps represents an opportunity for an attacker to send convincing messages that appear to come from your domain. Getting to a DMARC reject policy with full coverage of legitimate sending sources is the goal, and it is achievable for most organisations with a structured approach.

To discuss email authentication configuration for your domain, contact Cyberlinx at info@cyberlinx.com.au.