Skip to main content
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.
1

Audit all services that send email on your behalf

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.
2

Build a complete SPF record

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.
3

Change the SPF policy to hardfail

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.
4

Verify the record with a DNS lookup

Confirm your updated SPF record is published and syntactically correct.
Your hardened SPF record should look similar to this example — adapt it to include only the senders your audit identified:
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.
1

Enable DKIM signing in your email provider

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.
2

Publish the DKIM public key in DNS

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.
3

Verify DKIM is signing outbound mail

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.
4

Rotate DKIM keys at least annually

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.
1

Start with p=none to collect reports

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.
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.
2

Review aggregate reports for all sending sources

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.
3

Move to p=quarantine

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.
Continue monitoring aggregate reports for at least one to two weeks at this policy level before advancing.
4

Move to p=reject for maximum protection

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.
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.
1

Test with an external validation tool

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.
2

Confirm Leverage Cyber clears the finding

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.
3

Monitor for regressions

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.