SPF, DKIM, and DMARC: Protect Your Company from Email Spoofing

Email Spoofing: The Problem Nobody Talks About

Here is something most business owners don't realize: anyone can send an email that appears to come from your domain. Right now, without any technical skill, an attacker can send an email that looks like it comes from ceo@yourcompany.ch. The recipient's email client will display your company name, your domain, and nothing to indicate the message is fake.

This is not a bug. It is how email was designed. The Simple Mail Transfer Protocol (SMTP), created in 1982, includes no built-in mechanism for verifying the sender's identity. When you send a letter through the postal system, you can write any return address you want. SMTP works the same way.

The consequences are severe. The FBI's Internet Crime Complaint Center (IC3) reported that Business Email Compromise (BEC) caused over $2.9 billion in losses in 2023 alone. That number only counts reported incidents in the United States. The global figure is much higher.

Three protocols were developed to fix this gap: SPF, DKIM, and DMARC. Together, they form a layered authentication system that allows receiving mail servers to verify that an email genuinely came from an authorized sender. If you're running a business in Lugano or anywhere in Switzerland and haven't configured these three records, your domain is an open target.

How Email Delivery Actually Works

Before diving into the protocols, you need to understand the email delivery chain. When someone sends an email, it passes through several stages:

1. Composition: The sender writes the email in their mail client (Outlook, Gmail, Thunderbird).
2. Submission: The client connects to the sender's outgoing mail server (SMTP server) and submits the message.
3. Routing: The sending server looks up the recipient's domain MX (Mail Exchange) records in DNS to find the destination server.
4. Delivery: The sending server connects to the receiving server and transfers the message using SMTP.
5. Reception: The receiving server stores the message in the recipient's mailbox.

The critical point is step 4. During the SMTP conversation, the sending server announces a "MAIL FROM" address (the envelope sender) and the message itself contains a "From:" header. These two values can be completely different, and neither is verified by default. The receiving server simply trusts whatever it's told.

SPF: Sender Policy Framework

What SPF Does

SPF is the simplest of the three protocols. It answers one question: "Is this server allowed to send email for this domain?" You publish a DNS TXT record that lists every IP address and mail server authorized to send on behalf of your domain. When a receiving server gets an email claiming to be from your domain, it checks the SPF record to see if the sending server's IP is on the list.

How to Configure SPF

An SPF record is a DNS TXT record published at the root of your domain. Here is a practical example:

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:sendgrid.net -all

Let's break this down:

• v=spf1 - Declares this is an SPF record (version 1).
• ip4:203.0.113.0/24 - Authorizes all IP addresses in this range (your own mail server).
• include:_spf.google.com - Authorizes Google Workspace's mail servers.
• include:sendgrid.net - Authorizes SendGrid's servers (for transactional email).
• -all - Reject (hard fail) any email from servers not listed above.

The -all mechanism is critical. Many configurations use ~all (soft fail) instead, which tells receiving servers to accept the email but mark it as suspicious. This is weaker and should only be used during initial testing. In production, always use -all.

SPF Limitations

SPF has two significant weaknesses:

• It only validates the envelope sender (MAIL FROM), not the From: header. An attacker can set the envelope sender to their own domain (passing SPF) while displaying your domain in the From: header that the user sees.
• It breaks when email is forwarded. If a recipient has email forwarding set up, the forwarding server sends the email from its own IP, which won't be in your SPF record. This causes legitimate emails to fail SPF checks.
• 10 DNS lookup limit. SPF records are limited to 10 DNS lookups. Each include: mechanism triggers a lookup, and the included records may themselves contain further includes. Exceeding this limit causes SPF validation to fail for all emails.

These limitations are exactly why SPF alone is not enough. You need DKIM and DMARC to complete the picture.

DKIM: DomainKeys Identified Mail

What DKIM Does

DKIM adds a cryptographic signature to every outgoing email. The sending server signs the message (or specific headers) with a private key. The corresponding public key is published as a DNS TXT record. The receiving server retrieves the public key, verifies the signature, and confirms that the email was not tampered with in transit and was sent by a server holding the private key.

How DKIM Works Technically

When your mail server sends an email, the DKIM process works as follows:

1. The server selects which headers and body content to sign (typically From, To, Subject, Date, and the body).
2. It computes a hash of the selected content.
3. The hash is encrypted with the domain's private key using RSA or Ed25519.
4. The resulting signature is added as a DKIM-Signature header in the email.

A DKIM signature header looks like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=yourcompany.ch; s=selector1;
  h=from:to:subject:date:message-id;
  bh=base64encodedBodyHash;
  b=base64encodedSignature

Key fields:

• d= - The signing domain.
• s= - The selector, used to locate the public key in DNS.
• h= - The list of signed headers.
• b= - The actual signature.
• bh= - Hash of the message body.

The receiving server looks up the public key at selector1._domainkey.yourcompany.ch in DNS. If the signature validates, the email passes DKIM.

Configuring DKIM

DKIM configuration varies by email provider:

• Google Workspace: Generate DKIM keys in the admin console under Apps > Google Workspace > Gmail > Authenticate email. Google provides the DNS record to publish.
• Microsoft 365: DKIM is enabled by default for the onmicrosoft.com domain. For custom domains, configure it in the Exchange admin center under Mail flow > DKIM.
• Self-hosted (Postfix): Install OpenDKIM, generate a key pair, configure the milter, and publish the public key in DNS.

DKIM keys should be at least 2048 bits. Rotate them annually. Keep the private key secure; if it is compromised, an attacker can sign emails as your domain.

DKIM Advantages Over SPF

DKIM survives email forwarding because the signature travels with the message. It also validates the content of the email, not just the sending server. If someone intercepts and modifies the email in transit, the signature breaks. This provides integrity verification that SPF cannot offer.

DMARC: Domain-based Message Authentication, Reporting & Conformance

What DMARC Does

DMARC ties SPF and DKIM together and adds a policy layer. It tells receiving servers what to do when an email fails both SPF and DKIM checks. Without DMARC, the receiving server makes its own judgment about what to do with failed emails. With DMARC, you define the policy.

DMARC also introduces the concept of "alignment." This is the key feature that closes the spoofing gap left by SPF alone. DMARC requires that the domain in the From: header (what the user sees) matches the domain validated by SPF or DKIM. An email must pass at least one of these aligned checks to pass DMARC.

DMARC Record Configuration

A DMARC record is a DNS TXT record published at _dmarc.yourcompany.ch:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourcompany.ch; ruf=mailto:dmarc-forensics@yourcompany.ch; adkim=s; aspf=s; pct=100

Breaking this down:

• v=DMARC1 - Protocol version.
• p=reject - Policy: reject emails that fail DMARC. Other options are none (monitor only) and quarantine (send to spam).
• rua= - Address for aggregate reports (daily XML summaries of authentication results).
• ruf= - Address for forensic reports (details of individual failed messages).
• adkim=s - Strict DKIM alignment (the DKIM signing domain must exactly match the From: domain).
• aspf=s - Strict SPF alignment (the envelope sender must exactly match the From: domain).
• pct=100 - Apply the policy to 100% of messages.

The DMARC Deployment Path

You should never jump straight to p=reject. The recommended deployment path is:

1. Monitor (p=none): Start here. Set the policy to none and collect aggregate reports for 2-4 weeks. The reports will show you every server sending email as your domain, including legitimate services you may have forgotten about (marketing platforms, CRM systems, ticketing tools).
2. Audit: Review the reports. Add SPF includes and DKIM signatures for every legitimate sending source. Identify and stop any unauthorized senders.
3. Quarantine (p=quarantine): Move to quarantine. Failed emails go to spam folders instead of being delivered normally. Monitor for any legitimate emails being affected.
4. Reject (p=reject): Once you're confident that all legitimate senders are properly authenticated, set the policy to reject. Failed emails are dropped entirely.

This phased approach typically takes 4-8 weeks. Rushing it risks blocking your own legitimate email.

Business Email Compromise: Real Scenarios

The CEO Fraud Pattern

A finance employee at a mid-sized company in Ticino receives an email that appears to come from the CEO. The email says: "I need you to process an urgent wire transfer to a new supplier. This is confidential, please handle it directly and don't mention it to others. I'll explain in our meeting tomorrow." The email address shows the CEO's name and the company domain. The finance employee processes the transfer. The money goes to an account controlled by the attacker. By the time anyone realizes what happened, the funds have been moved through multiple jurisdictions and are unrecoverable.

This exact scenario plays out hundreds of times per month across Europe. Without DMARC set to reject, there is nothing stopping an attacker from sending that email.

The Invoice Redirection Scam

An attacker monitors publicly available information about a company's suppliers (from LinkedIn, press releases, or previous data breaches). They send an email spoofing the supplier's domain to the company's accounts payable department: "Our banking details have changed. Please update our payment information to the following account." The email looks legitimate because the From: address matches the supplier's domain. If the supplier hasn't configured DMARC, the receiving company has no way to detect the spoofing.

The Phishing Campaign

An attacker sends thousands of emails spoofing your company domain to your customers. The emails contain a link to a fake login page that harvests credentials. Your customers lose trust in your brand. You receive complaints and potentially face regulatory scrutiny under GDPR for failing to protect customer data, even though the phishing emails didn't originate from your infrastructure. For more on phishing attacks targeting businesses, see our article on business email phishing.

Common Configuration Mistakes

Mistake 1: SPF with ~all Instead of -all

Using soft fail (~all) instead of hard fail (-all) tells receiving servers that unauthorized senders should be treated with suspicion but not rejected. Most modern email providers ignore soft fail and deliver the email normally. This gives you a false sense of security while providing almost no protection.

Mistake 2: Exceeding the SPF 10-Lookup Limit

Every include:, a:, mx:, and redirect: mechanism in your SPF record triggers a DNS lookup. If you use Google Workspace, SendGrid, Mailchimp, HubSpot, and Salesforce, you might already be at 8-10 lookups. Add one more service and your entire SPF record breaks. Use SPF flattening tools to replace nested includes with direct IP ranges, but maintain them carefully as provider IPs can change.

Mistake 3: DMARC at p=none Permanently

Many organizations set DMARC to p=none and never progress beyond monitoring mode. This provides zero protection against spoofing. It only generates reports. If you've been at p=none for more than a month and haven't reviewed the reports, you're getting the worst of both worlds: no protection and no intelligence.

Mistake 4: Forgetting Third-Party Senders

Your company probably sends email from more places than you think: the main email provider (Google, Microsoft), a marketing platform (Mailchimp, ActiveCampaign), a CRM (Salesforce, HubSpot), a support ticket system (Zendesk, Freshdesk), a transactional email service (SendGrid, Postmark), and possibly your web server (contact form notifications). Every one of these needs to be included in your SPF record and configured for DKIM signing.

Mistake 5: Not Monitoring DMARC Reports

DMARC generates XML reports that are virtually unreadable by humans. Most organizations set up the rua= address and never look at the reports. Use a DMARC reporting service (dmarcian, Postmark DMARC, Valimail) to parse and visualize the data. Without monitoring, you won't know if legitimate email is being blocked or if an attacker is actively spoofing your domain.

Step-by-Step Configuration Guide

Step 1: Inventory All Email Senders

Before touching DNS, list every system that sends email using your domain. Ask each department: "What tools send email on behalf of our company?" Include:

• Primary email provider
• Marketing automation platforms
• CRM systems
• Support/ticketing systems
• Transactional email services
• Web application servers
• Any SaaS tool that sends notifications as your domain

Step 2: Configure SPF

Build your SPF record with all authorized senders:

v=spf1 include:_spf.google.com include:sendgrid.net include:mail.zendesk.com ip4:YOUR.SERVER.IP -all

Verify the record with an SPF checker tool. Ensure you're under the 10-lookup limit.

Step 3: Configure DKIM for Each Sender

Set up DKIM signing for each authorized sending service. Each service will provide a public key to publish in DNS. You'll typically have multiple DKIM records with different selectors.

Step 4: Deploy DMARC in Monitor Mode

v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.ch; pct=100

Wait 2-4 weeks and analyze the reports.

Step 5: Fix Authentication Failures

The reports will reveal any legitimate senders that are failing SPF or DKIM. Fix each one before moving to enforcement.

Step 6: Move to Quarantine, then Reject

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.ch; pct=100

After 2 weeks with no legitimate failures, move to reject:

v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.ch; ruf=mailto:dmarc-forensics@yourcompany.ch; adkim=s; aspf=s; pct=100

Verification and Testing

After configuration, verify everything works:

• SPF check: Use dig TXT yourcompany.ch or online tools like MXToolbox.
• DKIM check: Send a test email and examine the headers for DKIM-Signature and dkim=pass.
• DMARC check: Use dig TXT _dmarc.yourcompany.ch to verify the record.
• Full authentication test: Send an email to check-auth@verifier.port25.com or use mail-tester.com. These services provide a detailed report of all authentication checks.

Beyond SPF, DKIM, and DMARC

BIMI: Brand Indicators for Message Identification

BIMI is a newer standard that builds on DMARC. Once you have DMARC at p=quarantine or p=reject, you can publish a BIMI record that tells receiving email clients to display your company logo next to your emails. This provides visual trust signals to recipients and makes spoofed emails (which won't have the logo) more obviously suspicious.

MTA-STS: SMTP MTA Strict Transport Security

MTA-STS ensures that email sent to your domain is encrypted in transit using TLS. Without it, a man-in-the-middle attacker could downgrade the connection to unencrypted SMTP and intercept emails. MTA-STS publishes a policy that tells sending servers to only deliver email over encrypted connections.

Conclusion

Email authentication is not optional in 2025. If your domain doesn't have SPF, DKIM, and DMARC configured with an enforcement policy, you are actively allowing attackers to impersonate your company. The setup takes a few hours and costs nothing beyond the time invested. The potential losses from BEC fraud, phishing damage, and brand reputation harm run into the millions.

If you're unsure about your current email authentication status or need help configuring these protocols, contact our team. We can audit your DNS records, identify gaps, and implement a proper authentication chain that protects your domain and your customers.