Email is 50 years old and remains the number one attack vector — year after year. Not because we lack the tools to change that. We have them. SPF, DKIM and DMARC are standards that have existed for years and effectively block spoofing and phishing. The problem is that most organizations still haven’t implemented them correctly — or haven’t implemented them at all. This article changes that. Step by step, from the basics to policy enforcement and BIMI.
Why Does Email Remain the Primary Attack Vector Against Organizations?
Before diving into the technical details, it’s worth understanding why email is such an attractive target. Data from industry reports for 2025 leaves no room for doubt: more than 90% of ransomware and APT attacks begin with a malicious email. Phishing accounts for nearly half of all data breaches in the enterprise sector. Despite decades of awareness campaigns and training, this figure has not dropped significantly.
The reason is structural. Email is a protocol from the 1970s, designed without authentication mechanisms. By default, anyone can send a message with any address in the “From:” field. Mail servers do not verify whether the sender is actually authorized to use a given domain. This means an attacker can impersonate a company’s CEO, a bank, or an IT vendor — and only proper configuration on the recipient’s domain side can make this difficult or impossible.
On top of that, there is the sheer reach. Every organization — from a sole trader to a corporation — uses email. Every employee, from reception to the boardroom, can be an entry point. CEO phishing (Business Email Compromise, BEC) generates losses counted in billions of dollars globally every year. According to the FBI Internet Crime Complaint Center, BEC was responsible for losses exceeding $2.7 billion in 2022 alone — and the upward trend continued in subsequent years.
A further problem is the scale of attack personalization. Spear phishing — phishing targeted at a specific individual or organization — leverages information from LinkedIn, social media, data breaches and public records. A message that looks like an authentic email from a Chief Financial Officer, written in flawless English, with the correct signature and footer, is difficult to distinguish from the real thing — especially when the attacker uses a domain that looks visually similar to the company’s own (a homograph attack or typosquatting).
Technical defensive mechanisms such as SPF, DKIM and DMARC do not eliminate all threats — they cannot replace employee training or an ATP-class system. But they constitute the foundation without which no other layer of protection can function effectively. An organization without a correctly deployed DMARC in reject mode is an organization whose domain can be spoofed by literally anyone.
📚 Read the complete guide: OT/ICS Security: Bezpieczeństwo systemów OT/ICS - różnice z IT, zagrożenia, praktyki
What Are SPF, DKIM and DMARC — How Do They Protect Against Spoofing?
SPF, DKIM and DMARC are three complementary email authentication standards. Each one addresses a different aspect of the problem, and together they form a multi-layered shield against spoofing and phishing.
SPF (Sender Policy Framework) — RFC 7208 — is a DNS record published by the domain owner that specifies which mail servers are authorized to send emails on behalf of that domain. When a recipient’s server receives a message, it checks the sender’s server IP address against the SPF record. If the address is not on the list, the message is flagged as untrusted or rejected. SPF protects against attacks on the message envelope (the MAIL FROM command), but does not verify the From: header visible to the user.
DKIM (DomainKeys Identified Mail) — RFC 6376 — is a mechanism for cryptographically signing messages. The sending server attaches a digital signature to each email using a private key. The public part of the key is published in DNS. The recipient’s server retrieves the public key and verifies the signature — if the message content or headers have been modified in transit, the verification will fail. DKIM guarantees message integrity and authenticates the signing domain, but on its own says nothing about what to do with an unsigned message.
DMARC (Domain-based Message Authentication, Reporting and Conformance) — RFC 7489 — is a policy that ties together SPF and DKIM. The domain owner publishes a DMARC record informing recipient servers what to do with messages that fail SPF or DKIM verification: nothing (none), mark as spam (quarantine), or reject (reject). A key element of DMARC is the concept of alignment: the domain in the From: header must match the domain that passed SPF or DKIM. This is precisely what DMARC closes — the gap that SPF and DKIM leave when used separately.
📚 Read the complete guide: Email Security: Email Security — how to protect your company against ransomware and phishing
The DMARC reporting mechanism is a separate and very practical benefit. Once a DMARC record is deployed in none mode, the domain owner begins receiving XML reports from all major mail providers (Google, Microsoft, Yahoo, etc.) containing information about who is sending emails from their domain and whether those emails pass verification. This is an invaluable source of data for diagnosing and eliminating unauthorized senders.
How to Correctly Configure SPF — Syntax, Limits, include vs redirect?
An SPF record is a TXT record published in DNS for a domain. It begins with v=spf1, followed by a list of mechanisms specifying authorized servers, and ends with an all directive.
An example of a complete SPF record for an organization using Microsoft 365 and Sendgrid:
v=spf1 include:spf.protection.outlook.com include:sendgrid.net ip4:203.0.113.10 -allThe meaning of each element:
v=spf1— the SPF version identifier (always the same)include:spf.protection.outlook.com— includes the list of Microsoft 365 serversinclude:sendgrid.net— includes the list of Sendgrid serversip4:203.0.113.10— authorizes a specific IPv4 address (e.g. a server sending notifications from an internal application)-all— hard directive: any server not on the list is rejected (-allmeansfail;~allmeanssoftfail)
Critical limit: a maximum of 10 DNS lookups. This is the most common mistake in SPF configuration. Each include:, a:, mx:, ptr: mechanism generates a DNS lookup. If the total exceeds 10, the entire SPF record is treated as an error, which effectively disables protection. The ip4: and ip6: mechanisms do not generate DNS lookups and do not count toward the limit.
How to work around the 10-lookup limit? Use SPF flattening tools. Services such as dmarcian, MxToolbox SPF Flattener, or custom scripts retrieve all IP addresses from the include: chain and replace them with direct ip4: entries. The result is the same, but the number of DNS lookups drops to a minimum. The drawback is the need to refresh regularly — if a provider changes its IPs, your SPF record becomes outdated.
include: vs redirect= — the difference matters. The include: mechanism incorporates an external SPF policy as part of its own and continues processing further rules. redirect= replaces the entire SPF policy with the one from the specified domain — useful when several domains share an identical policy and you want to manage it centrally. redirect= ignores the all directive in the current record (because it transitions to another), so use it with caution.
When deploying SPF, start with ~all (softfail), observe the results for 2–4 weeks in DMARC reports, and after identifying all senders, switch to -all (fail). Never leave +all — that means you are authorizing every server in the world.
How to Deploy DKIM — Key Generation and Message Signing?
DKIM requires action on two sides: the mail server must be configured to sign messages, and the public key must be published in DNS.
Step 1: Generate the key pair. For Microsoft 365 and Google Workspace the entire process takes place in the admin console — the platforms generate keys for you. For other servers (Postfix, Exim, sendmail) use opendkim-genkey:
opendkim-genkey -b 2048 -d yourdomain.com -s selector1Parameters: -b 2048 is the key length (minimum 1024 bits, 2048 recommended), -d is the domain, -s is the so-called selector — an identifier that allows multiple DKIM keys for a single domain (e.g. different servers, key rotation). The command generates two files: selector1.private (the private key, goes on the mail server) and selector1.txt (the public key for DNS).
Step 2: Publish the public key in DNS. The TXT record goes under the subdomain selector._domainkey.yourdomain.com. Example:
selector1._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0B..."Record elements: v=DKIM1 is the version, k=rsa is the algorithm (RSA; newer servers also support k=ed25519), p= is the public key encoded in Base64.
Step 3: Configure the mail server. In OpenDKIM (a typical Linux environment) configuration involves specifying the private key, selector and domain in the /etc/opendkim.conf file and connecting the service to the Postfix server via a milter (mail filter). Detailed configuration depends on the distribution — consult the OpenDKIM documentation for your system.
DKIM key rotation is a security practice that many organizations neglect. The industry recommendation is rotation every 6–12 months. The process: generate a new key pair with a new selector (e.g. selector2), publish the public key in DNS, configure the server to sign with the new key, and remove the old key from DNS after 48–72 hours (TTL propagation time).
An RSA key length of 1024 bits is already considered insufficient. In December 2025, following further advances in quantum computing, the industry consensus clearly indicates a minimum of 2048 bits. If your server uses older keys — plan a rotation.
Verification of DKIM after deployment: send a test message to a Gmail or Outlook account and check the headers (View Original). The Authentication-Results header should contain dkim=pass.
How to Configure DMARC — From Monitoring to Enforcement?
DMARC is a TXT record published under _dmarc.yourdomain.com. Minimal starting configuration:
_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; fo=1"Meaning of the parameters:
v=DMARC1— version identifierp=none— policy: do nothing with messages that fail verification (monitoring mode)rua=— address for aggregate reports (XML reports sent once a day by recipient servers)ruf=— address for forensic reports (detailed reports about specific failed messages; not all providers send these)fo=1— generate a forensic report if SPF or DKIM fails (not only when both fail)
Three stages of DMARC deployment:
Stage 1 — Monitoring (p=none). Deploy the record, collect reports for a minimum of 4 weeks. XML reports are technical — use a tool to parse them: dmarcian, Postmark DMARC, Google Postmaster Tools, or the open-source parsedmarc. The goal of this stage is to identify all mail streams sent from your domain: the corporate server, marketing platform, CRM system, helpdesk, application notifications, automations.
Stage 2 — Quarantine (p=quarantine). After identifying and correctly configuring all senders (each must pass SPF or DKIM with alignment), change the policy to quarantine. Unauthorized messages go to the spam folder instead of the inbox. This is a significant step — observe for another 2–4 weeks.
Stage 3 — Enforcement (p=reject). Full protection. Unauthorized messages are rejected at the recipient server level. This is the goal every organization that takes email security seriously should aim for.
Additional DMARC parameters worth noting:
pct=50— apply the policy to only 50% of non-compliant messages (useful for gradual deployment at thequarantinestage)sp=reject— policy for subdomains (if not specified, subdomains inherit the policy of the parent domain)adkim=s— DKIM alignment in strict mode (s=strict: theFrom:domain must be identical;r=relaxed: subdomains are accepted)aspf=s— SPF alignment in strict mode
Flashcard: DMARC alignment. Simply passing SPF or DKIM is not sufficient for DMARC. Alignment must also be satisfied: the domain in
From:must match the domain that passed SPF or DKIM. Sending via a third-party service with a foreign SPF domain (e.g. a Mailchimp server with its own SPF domain) without a DKIM signature from your domain will not pass DMARC — even if SPF showspass.
A typical mistake: an organization has SPF and DKIM correctly configured, but sends a newsletter through a marketing platform that signs DKIM with its own domain. DMARC does not accept this. The solution: either configure a DKIM subdomain for the marketing platform (many platforms allow this), or configure your own DKIM through the platform (custom domain DKIM).
How to Deploy BIMI — Your Company Logo in the Recipient’s Inbox?
BIMI (Brand Indicators for Message Identification) is a relatively new standard that allows a company logo to be displayed next to email messages in recipients’ inboxes. This is a benefit both for marketing (brand recognition) and security (users can more easily identify authentic messages).
The prerequisites for BIMI are clear: you must have DMARC deployed at quarantine or reject level. Without this, BIMI will not work. This is one of the main reasons why Google and Yahoo have begun actively promoting BIMI — it pushes organizations toward full DMARC deployment.
Step 1: Prepare an SVG file with the logo. BIMI requires a very specific SVG format: Tiny PS profile (Tiny Portable/Secure), square viewport, no external resources, no scripts. Dimensions should be defined in the viewport, not in pixels. The SVG file must be hosted on an HTTPS server with a publicly accessible URL.
Validation of the SVG file: use the BIMI Group SVG validator (available online) or the bimi-inspector CLI. An incorrect SVG format is the most common cause of BIMI display problems.
Step 2: Obtain a VMC (Verified Mark Certificate). For displaying the logo on Gmail and Apple Mail, a Verified Mark Certificate is required — a certificate confirming trademark ownership and rights to the logo. In December 2025, VMCs are issued by two main certification authorities: DigiCert and Entrust. The cost of a VMC is typically a few hundred dollars per year. Requirement: the logo must be a registered trademark.
Some providers (e.g. Yahoo Mail) display BIMI without a VMC — they verify only the DNS record and the correctness of DMARC. However, for Gmail a VMC is required.
Step 3: Publish the BIMI record in DNS.
default._bimi.yourdomain.com TXT "v=BIMI1; l=https://yourdomain.com/logo.svg; a=https://yourdomain.com/cert.pem"Elements: v=BIMI1 is the version, l= is the URL of the SVG file, a= is the URL of the VMC certificate (if you have one). If you do not have a VMC, the a= parameter is omitted or left empty.
Step 4: Verification. Tools for checking BIMI: BIMI Group Inspector, MxToolbox BIMI Lookup. Displaying the logo may take a few days after publishing the record, because mail servers cache verification results.
BIMI is not a cryptographic security mechanism — it is a visual signal for the recipient. Its value lies in the fact that an attacker spoofing a domain without a VMC will not display a logo (because they don’t have the certificate), which helps users distinguish authentic messages from forged ones.
How to Protect Email Against Phishing — ATP, Sandbox, URL Rewriting?
SPF, DKIM and DMARC protect against domain spoofing. But phishing is a broader concept — an attacker can send malicious messages from their own, correctly authenticated domain. This is where advanced anti-malware and anti-spam protection mechanisms of the ATP (Advanced Threat Protection) class come in.
Attachment sandboxing is a mechanism that executes every suspicious file in an isolated virtual environment before delivering it to the recipient. The sandbox observes behavior: attempts to connect to a C2 server, registry modifications, file encryption, invocation of system processes. If the file behaves maliciously — it is blocked. Sandboxing technology is offered by, among others, Check Point SandBlast, Microsoft Defender for Office 365 (Safe Attachments), Proofpoint TAP, and Mimecast CTP.
URL rewriting (Safe Links) is the rewriting of all links in messages by a security gateway. When a user clicks a link, the gateway first checks the URL in real time (reputation, active threats, rendering the page in a sandbox), and only then redirects. This is crucial in combating so-called “time-of-click” phishing — where the phishing page is activated only after the message is delivered, in order to bypass static scanning.
Anti-impersonation and BEC protection. Modern ATP systems analyze communication patterns to detect attempts to impersonate individuals within the organization. The analysis includes: similarity of display names (John Smith vs John Sm1th), visually similar domains (homographic, typosquatting), new domains (recently registered, high risk), and header patterns characteristic of BEC.
AI-driven threat intelligence is another layer: machine learning models analyze billions of messages per day, identify new attack patterns and update signatures in real time. Platforms such as Proofpoint NEXUS, Mimecast AI and Microsoft Defender Intelligence operate on such large datasets that they are able to detect new phishing campaigns at a very early stage.
Employee education and phishing simulations remain an indispensable element of protection. Technical safeguards are the first line of defense, but an employee who clicks a link in a fake message from a correctly authenticated domain bypasses the entire ATP infrastructure. Phishing simulation platforms (KnowBe4, Proofpoint Security Awareness Training, Microsoft Attack Simulator) allow regular testing of employee vigilance and measurement of the susceptibility rate (click rate).
How to Secure Microsoft 365 and Google Workspace Against Email Threats?
Microsoft 365 and Google Workspace have built-in email protection mechanisms, but the default configuration is often not sufficient. Here are specific actions worth taking.
Microsoft 365 — key configurations:
Enable Microsoft Defender for Office 365 Plan 2 (if you have the license). Safe Attachments configuration: set the policy to Block or Dynamic Delivery (Dynamic Delivery delivers the message, replacing the attachment with a placeholder while sandbox analysis is in progress). Safe Links configuration: enable URL rewriting for email messages and Teams, activate “Track user clicks”, disable the “Allow users to click through to original URL” option.
Advanced anti-spoofing configuration in Defender: set an Anti-phishing policy with impersonation protection enabled for the domain and specified users (C-level). Mailbox intelligence — a feature that learns the communication patterns of a specific mailbox and detects anomalies — should be active for all users.
DKIM in Microsoft 365: configuration in the Defender admin center (protection.office.com → Email & collaboration → Policies & rules → Threat policies → DKIM). Click the domain, activate DKIM — the portal will generate two CNAME records to add in DNS. Using CNAME instead of TXT allows Microsoft to perform automatic key rotation.
Google Workspace — key configurations:
DKIM in Google Workspace: in Admin Console → Gmail → Authenticate email → Generate new record. Google uses the google selector, and the TXT record should be added to DNS under google._domainkey.yourdomain.com.
Enable Enhanced pre-delivery message scanning: Admin Console → Apps → Google Workspace → Gmail → Safety → Enhanced pre-delivery message scanning. This feature delays the delivery of suspicious messages by a few minutes to allow for deeper analysis.
Compliance rules: block automatic email forwarding outside the organization (a frequent BEC vector — the attacker creates a rule forwarding a copy of all emails to an external account). In M365: Exchange Admin Center → Mail flow → Rules. In Google Workspace: Admin Console → Gmail → Compliance → Content compliance.
Disable Basic Authentication — if still active in M365, block Basic Auth for all legacy protocols (POP3, IMAP, SMTP AUTH, EWS, MAPI over HTTP). Attackers use Basic Auth to bypass MFA. In M365, use Authentication Policies or Conditional Access.
Monitor reports in Microsoft Secure Score (security.microsoft.com). Secure Score provides a concrete list of actions with an assessment of their impact on security — an ideal tool for prioritizing the work of an administrator.
What Does an Email Security Implementation Roadmap Look Like?
Deploying full email protection is a multi-week project. The table below presents the recommended roadmap divided into stages, priorities and estimated completion times.
| Stage | Action | Priority | Completion Time | Outcome |
|---|---|---|---|---|
| 1 | Audit of current state (SPF, DKIM, DMARC lookup) | Critical | Day 1 | Starting point, identification of gaps |
| 2 | Inventory of all mail senders | Critical | Days 1–3 | List of services requiring configuration |
| 3 | Deployment/correction of SPF (~all) | High | Days 3–5 | Basic envelope protection |
| 4 | DKIM deployment on the primary mail server | High | Days 3–7 | Message integrity and authentication |
| 5 | DMARC p=none deployment + report configuration | High | Week 1 | Visibility of mail flows |
| 6 | Analysis of DMARC reports, configuration of missing senders | High | Weeks 2–4 | Elimination of false positives |
| 7 | Change SPF from ~all to -all | High | After stage 6 | Hard block of unauthorized servers |
| 8 | Change DMARC from none to quarantine (pct=50) | High | Weeks 4–6 | Partial policy enforcement |
| 9 | Escalate DMARC to quarantine (pct=100) | High | Weeks 6–8 | Full quarantine |
| 10 | Escalate DMARC to p=reject | Critical | Weeks 8–12 | Full protection against domain spoofing |
| 11 | ATP deployment (Safe Attachments, Safe Links) | High | In parallel | Protection against malicious content |
| 12 | Deployment of anti-impersonation protection | High | In parallel | Protection against BEC |
| 13 | Preparation of SVG logo, obtaining VMC | Medium | After stage 10 | BIMI prerequisite |
| 14 | BIMI deployment | Low | After stage 13 | Visual brand verification |
| 15 | Employee training + phishing simulations | High | Ongoing | Reduction of human vulnerability |
| 16 | Regular DKIM key rotation | High | Every 6–12 months | Continuity of cryptographic protection |
| 17 | Review and update of SPF (new senders) | High | Quarterly | Currency of the authorized server list |
The roadmap is indicative — the pace of implementation depends on the complexity of the email infrastructure. Organizations using exclusively Microsoft 365 or Google Workspace can complete the first 10 stages in 4–6 weeks. Companies with multiple systems (ERP, CRM, helpdesk, marketing automation) should reserve 8–12 weeks.
How Does nFlo Audit and Secure Clients’ Email Infrastructure?
nFlo works with more than 200 clients from the enterprise and SME sectors, delivering more than 500 projects in the area of cybersecurity — with a retention rate of 98% and a response time of under 15 minutes. Email security is one of the most common elements of our audits and implementation projects.
What does an nFlo email security audit look like?
The starting point is automated data collection: checking SPF, DKIM and DMARC records for the client’s domain and all subdomains, analysis of received message headers, verification of DKIM configuration (key length, selector, validity), and checking RBL lists (Real-time Blackhole Lists) — to determine whether the client’s mail servers appear on spam blocklists.
We then audit the server or cloud platform configuration: Microsoft 365 (Defender policies, DKIM, Exchange transport rules), Google Workspace (Gmail advanced settings, DKIM, compliance rules), on-premise (Postfix/Exim — TLS configuration, STARTTLS, relaying, rate limiting). We also verify DNS configuration for traps: too many include: mechanisms in SPF, missing DMARC records for subdomains, and expired DKIM keys.
Audit results take the form of a concrete report with a maturity score on a 0–100 scale for each category: authentication (SPF/DKIM/DMARC), malware protection (ATP/sandbox), phishing protection (URL rewriting, impersonation protection), TLS configuration, and BIMI readiness. Each finding has an assigned risk level (Critical / High / Medium / Low) and a recommendation with an estimated remediation time.
Implementation is always carried out while maintaining business continuity. The phased approach to DMARC — from none through quarantine to reject — guarantees that no legitimate message is lost. We carry out configuration across all of the client’s sending systems: mail server, CRM, marketing platform, helpdesk, ERP. Every sender is identified, authorized and verified before moving to the next stage.
Statistics from nFlo projects show that 90% of audited organizations have at least one critical gap in their email security configuration: missing DMARC, SPF with +all or without an all directive, 1024-bit DKIM keys, and lack of subdomain protection. After implementing the full stack (SPF + DKIM + DMARC reject + ATP), we observe a reduction of successful phishing attacks by more than 90% compared to the pre-implementation state.
If you want to assess the email security posture of your organization — contact nFlo. We can carry out an email security audit remotely within 2–3 business days.
Related Concepts
MTA-STS (Mail Transfer Agent Strict Transport Security) — a standard that enforces encrypted TLS connections between mail servers, complementing SPF/DKIM/DMARC at the transport layer.
DANE (DNS-based Authentication of Named Entities) — a mechanism binding TLS certificates to DNSSEC records, strengthening the security of encryption between MTA servers.
ARC (Authenticated Received Chain) — a protocol that preserves message authentication information when a message is forwarded through mailing lists or forwarders, where DMARC would otherwise block legitimate messages.
BEC (Business Email Compromise) — an attack involving impersonation of individuals within an organization or trusted vendors in order to fraudulently obtain payments or data.
DNSSEC — a DNS extension that adds cryptographic signing of DNS records, preventing cache poisoning — an important complement to SPF/DKIM/DMARC.
Learn More
- Email Security — how to protect your company against ransomware and phishing
- What is spoofing — types, mechanism, techniques
- Business Email Compromise — analysis and defense strategy
- Phishing in practice — how to recognize suspicious messages
- Harmony Email & Collaboration — secure email communication
Check Our Services
Looking for support with email security auditing and implementation? nFlo offers comprehensive email security audits, SPF/DKIM/DMARC deployment, and ATP system configuration for Microsoft 365 and Google Workspace.
Contact nFlo and find out how we can secure your organization’s email infrastructure.
FAQ — Frequently Asked Questions
Is implementing SPF, DKIM and DMARC technically difficult?
Basic SPF and DKIM deployment for a cloud platform (Microsoft 365, Google Workspace) does not require advanced technical knowledge — most steps involve configuration in the admin console and adding a few DNS records. The more challenging element is inventorying all systems sending email on behalf of the domain and correctly configuring DMARC with a phased transition to reject. Organizations with complex infrastructure (multiple systems, subdomains, legacy servers) should consider engaging an external specialist.
Why do I already have SPF and DKIM but my emails still land in spam?
Having SPF and DKIM alone does not guarantee deliverability. The most common causes are: missing DMARC (recipient servers treat messages as less trustworthy), server appearing on an RBL (blacklist), poor IP or domain reputation (history of spam), poor content quality (keywords triggering spam filters), and missing List-Unsubscribe header for bulk mailings. Diagnostic tools: Mail-tester.com, GlockApps Inbox Testing, Google Postmaster Tools (domain and IP reputation).
What free/open-source tools do you recommend for DMARC monitoring?
For analyzing DMARC reports without cost: parsedmarc (Python, open-source, export to Elasticsearch/Splunk), Postmark DMARC (free up to 10,000 messages per month), Google Postmaster Tools (domain reputation data for mail delivered to Gmail). For configuration verification: MxToolbox (SPF, DKIM, DMARC, blacklist lookup), Kitterman SPF Tester, DMARC.org Validator. For larger organizations it is worth considering paid platforms: dmarcian, Valimail, Agari — they offer advanced visualization, automated alerts and support in interpreting reports.
What will happen to marketing mailings after deploying DMARC reject?
If before switching to reject you correctly configure SPF and DKIM for the mailing platform (Mailchimp, Salesforce Marketing Cloud, Klaviyo, SendGrid, etc.), mailings will continue to function without any changes. All major mailing platforms support the configuration of your own domain in SPF and your own DKIM keys — this is a standard feature. The problem only arises when a mailing is sent from a domain without correct configuration, or when the platform signs DKIM with its own domain instead of yours. The DMARC monitoring stage (p=none + reports) exists precisely to identify such cases before enforcement is enabled.
How often should I audit my email security configuration?
The minimum recommendation is a review every quarter. In practice, an audit is necessary every time: a new system sending email is added (CRM, helpdesk, marketing platform), the email provider is changed, the DNS infrastructure changes, a new domain or subdomain is deployed, or DKIM keys are rotated. Automated monitoring — alerts when the SPF record is incorrect, DKIM fails, or DMARC records expire — is worth deploying as part of ongoing security monitoring (e.g. through dmarcian or Valimail platforms with email/Slack alerts).
Sources
- RFC 7208 — Sender Policy Framework (SPF): https://tools.ietf.org/html/rfc7208
- RFC 6376 — DomainKeys Identified Mail (DKIM): https://tools.ietf.org/html/rfc6376
- RFC 7489 — Domain-based Message Authentication, Reporting and Conformance (DMARC): https://tools.ietf.org/html/rfc7489
- BIMI Group — Brand Indicators for Message Identification: https://bimigroup.org
- FBI Internet Crime Complaint Center — IC3 Annual Report 2022: https://www.ic3.gov/Media/PDF/AnnualReport/2022_IC3Report.pdf
- Google Postmaster Tools: https://postmaster.google.com
- Microsoft Defender for Office 365 Documentation: https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/
- MxToolbox Email Header Analyzer: https://mxtoolbox.com
- parsedmarc — Open-source DMARC Report Analyzer: https://github.com/domainaware/parsedmarc
- DMARC.org — Industry Resources: https://dmarc.org
