> ## Documentation Index
> Fetch the complete documentation index at: https://docs.leveragecyber.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Email Hardening: Fix SPF, DKIM, and DMARC Misconfigurations
> Step-by-step guidance for implementing strong SPF, DKIM, and DMARC records to eliminate email spoofing findings and protect your domain.
Email spoofing is one of the simplest attacks to execute and one of the most preventable. An attacker who can send email that appears to come from your domain can phish your customers, impersonate your executives, and bypass recipient spam filters — all without ever touching your infrastructure. This guide walks you through hardening your email authentication records step by step, so you can eliminate or significantly reduce email-based findings surfaced in Leverage Cyber and close the door on one of the most commonly exploited attack vectors in the wild.
## Step 1 — Harden Your SPF Record
SPF (Sender Policy Framework) tells receiving mail servers which IP addresses and services are authorized to send email on behalf of your domain. A missing or overly permissive SPF record means anyone can forge your domain as the sender.
Before you change anything, build a complete inventory of every service that sends email using your domain. Common sources include your primary email provider (Google Workspace, Microsoft 365), marketing automation platforms (HubSpot, Mailchimp, Marketo), CRM systems (Salesforce), transactional email services (SendGrid, Postmark, AWS SES), and any internally hosted applications that send notifications or alerts. Missing a legitimate sender from your SPF record will cause their mail to fail authentication after you enforce hardfail.
Construct your SPF record to include every authorized sending source identified in your audit. Each service's documentation will provide the `include:` value or IP range to add. Keep your lookup chain under ten DNS lookups — exceeding this limit causes SPF to return a `permerror`, which some receivers treat as a failure.
Locate your current SPF TXT record and change the trailing `~all` (softfail) to `-all` (hardfail). Softfail tells receivers to accept the mail but mark it as suspicious; hardfail tells receivers to reject it outright. Until you enforce `-all`, SPF provides almost no real protection — receivers ignore softfail in practice.
Confirm your updated SPF record is published and syntactically correct.
```bash theme={null}
dig TXT yourdomain.com | grep spf
```
Your hardened SPF record should look similar to this example — adapt it to include only the senders your audit identified:
```
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all
```
Validate the record using an SPF checking tool to confirm the lookup count is within limits and there are no syntax errors before moving on.
If you have multiple subdomains that send email, each one needs its own SPF record. Subdomains do not inherit the parent domain's SPF policy. If a subdomain should never send email, publish `v=spf1 -all` for it to explicitly reject all mail claiming to originate from that subdomain.
## Step 2 — Configure DKIM
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to outbound messages that receiving servers verify against a public key published in your DNS. It proves that a message claiming to come from your domain was actually sent by an authorized system and that the message body was not altered in transit.
Navigate to the email authentication or security settings in your email provider's admin console. For **Google Workspace**, go to Admin Console → Apps → Google Workspace → Gmail → Authenticate Email, then generate a new DKIM key. For **Microsoft 365**, go to the Defender portal → Email & Collaboration → Policies & Rules → Threat Policies → Email Authentication Settings → DKIM. Enable DKIM for each domain you control. Most providers generate a 2048-bit RSA key — prefer 2048-bit over 1024-bit wherever your provider offers the choice.
Your email provider will give you a TXT record to add to DNS. The record name follows the format `selector._domainkey.yourdomain.com`, where `selector` is a label chosen by your provider (commonly `google`, `s1`, or `selector1`). Add the record exactly as provided. DNS propagation can take up to 48 hours, but is typically complete within a few hours.
```
google._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0..."
```
Send a test email from the domain to an external mailbox you control (Gmail is a reliable test destination). Open the message, view the full headers, and look for a `DKIM-Signature` header. In Gmail, use the "Show original" option to inspect headers directly. Confirm the `d=` tag matches your domain and the `s=` tag matches the selector you published. A `dkim=pass` result in the `Authentication-Results` header confirms successful signing.
DKIM private keys should be rotated on a regular schedule — at minimum once per year, or immediately if you suspect the key has been compromised. Most email providers support multiple simultaneous selectors, which allows you to publish a new key and phase out the old one without interrupting mail delivery. Add a DKIM key rotation reminder to your security calendar.
## Step 3 — Enforce DMARC
DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together and tells receiving mail servers what to do with messages that fail both checks. It also provides aggregate and forensic reporting so you can see who is sending mail claiming to use your domain.
Publish an initial DMARC record with `p=none`. This monitoring-only mode generates reports without affecting mail delivery. You'll start receiving aggregate reports (RUA) from major receivers — Google, Microsoft, Yahoo, and others — showing you every source sending mail that claims to be from your domain.
```
_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100"
```
Set up the `rua` mailbox before you publish the record. Third-party DMARC report processing services (such as Postmark, Dmarcian, or Valimail) can parse the XML reports into a readable dashboard if you prefer not to process them manually.
Spend a minimum of two weeks reviewing DMARC aggregate reports at `p=none`. Identify every source sending mail on behalf of your domain — both legitimate senders you may have missed during your SPF audit and unauthorized sources attempting to spoof your domain. For each legitimate source that is failing DMARC, update your SPF record to include it or confirm its DKIM signing is active. Do not advance to the next policy level until all legitimate senders pass DMARC alignment.
Once you're confident all legitimate senders pass both SPF and DKIM, advance your DMARC policy to `p=quarantine`. This instructs receiving servers to route failing messages to spam/junk rather than rejecting them outright, giving you a safety net while you confirm nothing legitimate is being caught.
```
_dmarc.yourdomain.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100"
```
Continue monitoring aggregate reports for at least one to two weeks at this policy level before advancing.
Advance to `p=reject` once you've verified no legitimate mail is landing in quarantine. At `p=reject`, receivers discard messages that fail DMARC outright — they are never delivered and never shown to the recipient. This is the only policy level that fully prevents domain spoofing.
```
_dmarc.yourdomain.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; pct=100"
```
Keep the `rua` reporting address active even after you reach `p=reject`. Reports continue to provide visibility into spoofing attempts and will alert you if a new legitimate sender starts failing DMARC after a configuration change.
Never rush from `p=none` directly to `p=reject`. Always spend at least two weeks at `p=none` reviewing DMARC aggregate reports before moving to any enforcing policy. Skipping this step is one of the most common causes of legitimate business email being blocked — marketing campaigns, transactional notifications, and automated alerts can all fail DMARC if their sending sources were not included in your SPF record or configured with DKIM signing. A blocked email pipeline is a serious operational disruption. Take the time to do this right.
## Verification and Monitoring
After completing all three steps, run a full verification to confirm your configuration is correct end to end.
Use a tool such as MXToolbox, mail-tester.com, or Google's Admin Toolbox to check your SPF, DKIM, and DMARC records simultaneously. Send a test message to mail-tester.com and review the full authentication report — it will flag any alignment issues between SPF, DKIM, and your DMARC policy.
Leverage Cyber's continuous monitoring passively re-checks your DNS records on an ongoing basis. Once your SPF record uses `-all`, your DKIM key is published and verified, and your DMARC policy is at `p=quarantine` or `p=reject`, the corresponding findings will automatically update in your dashboard. You do not need to manually trigger a rescan — the platform detects the configuration change and closes the finding at the next monitoring cycle.
Email authentication misconfigurations have a habit of reappearing. New services get onboarded without being added to SPF. DKIM keys expire or get accidentally deleted. DMARC policies get rolled back during a mail delivery incident and never re-enforced. Leverage Cyber's continuous monitoring watches for these regressions and will re-open or create new findings if your configuration degrades after remediation.
Assign a named owner for email authentication configuration — typically someone on your IT or infrastructure team who is the authoritative contact for DNS changes. Ownership without a name is no ownership at all. Document the current configuration, the selectors in use, key rotation dates, and the DMARC reporting mailbox in your internal runbook so that whoever is on call during an email delivery incident has the context they need to act quickly.