Shieldome SiegeShieldome Siege
Technique

SPF, DKIM, and DMARC Explained

Of all the findings a domain posture review turns up, email spoofing gaps are among the easiest to fix and among the most commonly left unfixed. All three of the relevant controls live entirely in DNS, and none of them require touching a mail server's configuration directly.

SPF: who is allowed to send as your domain

Sender Policy Framework is a DNS record listing which mail servers are authorized to send email on behalf of your domain. A receiving mail server checks the sending server's IP address against that list. Without an SPF record, or with one that is too permissive, anyone can send email that claims to be from your domain and receiving servers have no simple way to tell the difference.

DKIM: proving the message was not altered

DomainKeys Identified Mail adds a cryptographic signature to outgoing email, generated with a private key your mail server holds and verified against a public key published in your DNS. A receiving server can confirm both that the message actually came from a server holding your private key, and that its content was not modified in transit.

DMARC: telling receivers what to do about failures

Domain-based Message Authentication, Reporting, and Conformance ties SPF and DKIM together and tells receiving mail servers what to do when a message fails those checks: nothing, quarantine it, or reject it outright. A domain with SPF and DKIM configured but no DMARC policy, or a DMARC policy set to "none," is still leaving the actual enforcement decision up to whatever the receiving server feels like doing.

The most common gap: SPF and DKIM configured correctly, but DMARC either missing entirely or set to a monitoring-only policy indefinitely, which reports on spoofing attempts without actually stopping any of them.

Why this matters beyond spam filtering

A spoofed email from your own domain is a far more effective phishing lure against your own employees, your own customers, and your own vendors than one from an obviously unrelated address. Closing this gap is one of the highest-leverage, lowest-effort fixes available in a domain posture review, and it shows up constantly in engagements precisely because it requires no application changes, just DNS records most teams configured once and never revisited.

Where this fits in a broader review

Email and domain posture checks usually run alongside broader infrastructure review, cloud configuration, and supply chain exposure. None of them require exploitation to identify, which makes them a natural part of even a recon-only engagement scope.

See it in an actual tool

Shieldome Siege enforces scope on every action and gates exploit confirmation behind a human approval, with a tamper-evident audit log of the whole engagement.

Read the documentation