SMB1001:2027 DMARC and email authentication updates
News
SMB1001:2027 changes the Gold email control from requiring alignment with both SPF and DKIM to alignment with SPF or DKIM. This is the key DMARC change: an authenticated, aligned result from either mechanism satisfies the revised alignment wording. Silver also broadens its minimum from SPF alone to SPF or DKIM. Gold continues to require SPF, DKIM and DMARC configured, with p=quarantine or p=reject.
CyberCert's supplied update says certification against the 2027 edition applies from 1 January 2027. That statement does not establish an automatic expiry or reassessment date for existing certificates. The 2026 email security explainer provides earlier context, while the official DSI standard page remains the source to check for published standard information.
What changed for 2027
Comparing the 2026 and 2027 control excerpts shows two substantive email authentication changes: Silver permits DKIM as an alternative to SPF, and Gold changes the DMARC alignment requirement from both mechanisms to either one. Gold enforcement and annual or post-change DNS reviews appear in both editions.
|
|
|
|
|---|---|---|---|
Silver minimum | SPF | SPF or DKIM | Broader |
Gold alignment | SPF and DKIM | SPF or DKIM | Either suffices |
Gold protocols | All three | All three | Continues |
Gold DMARC policy | Quarantine or reject | Quarantine or reject | Continues |
Gold DNS review | Annual + major change | Annual + major change | Continues |
Comparison of the 2026 control excerpts and the 2027 excerpts.
The change is specifically to the alignment condition in Gold control iii(c). The separate requirements to configure SPF, sign outbound email with DKIM and publish an enforced DMARC policy remain in place.
Silver now accepts SPF or DKIM
Control 2.12.0.0 says all domains used to send organisational email must have SPF or DKIM configured. A client with DKIM correctly configured can therefore satisfy this email authentication minimum without SPF. Configuring both remains sensible operational advice, but it is not the minimum stated in this control. DMARC is also not part of this Silver minimum.
DSI SMB1001:2027 excerpt, control 2.12.0.0.
SPF authorises sending infrastructure through DNS. DKIM adds a cryptographic signature that a receiving system can verify. The control note recognises that implementation and maintenance can be complex and recommends working with their Technical Support Specialist or external IT provider under control 1.1.
Gold now accepts SPF or DKIM alignment
The 2026 Gold excerpt, control 2.12.1.0 iii(c), says to "ensure alignment with both SPF and DKIM". The 2027 excerpt, control 2.12.1.1 iii(c), changes this to "ensure alignment with SPF or DKIM". Requiring both aligned results is therefore no longer the wording of this condition.
DSI SMB1001:2027 excerpt, control 2.12.1.1.
This brings the control wording into line with how a message passes DMARC: either SPF must pass with an aligned domain, or DKIM must pass with an aligned signing domain. Alignment compares the authenticated domain with the domain in the visible From address. Under relaxed alignment, their organisational domains can match. A pass using an unrelated provider domain does not satisfy alignment.
2026 Gold wording
Alignment with both SPF and DKIM.
2027 Gold wording
Alignment with SPF or DKIM.
For example, a marketing service might sign email with an aligned DKIM domain while using its own, unaligned return-path domain for SPF. If that DKIM signature passes and is aligned with the visible From domain, the message passes DMARC and meets the revised alignment condition. The SPF result does not also have to be aligned. This example concerns alignment, not whether the organisation has fulfilled the control's other requirements.
Gold still requires SPF, DKIM and DMARC on every domain used to send organisational email. SPF must identify all authorised sending services, and DKIM signing must cover all outbound email using 1024-bit minimum or 2048-bit keys. We recommend 2048-bit DKIM where supported. DMARC must include a reporting address and use p=quarantine or p=reject; p=none remains a temporary discovery state, not the required enforcement policy.
Aggregate reports: The rua address receives aggregate DMARC data where participating receivers send it. The supplied excerpt does not require a forensic ruf address, and not every receiver sends reports.
A practical route to DMARC enforcement
Enforcement work should start with evidence, not a policy change. The standard calls for a specialist to manage implementation and ongoing DMARC report analysis. For an SMB, that owner can be the engaged specialist or IT provider. For an MSP, ownership should also be clear for each client domain.
- Inventory: List mailbox, CRM, marketing, invoicing and ticketing senders for every sending domain.
- Authenticate: Publish accurate SPF authorisation and enable DKIM signing across outbound services.
- Observe: Use p=none as a temporary discovery state with an aggregate report address.
- Diagnose: Classify report sources and investigate failures, forwarding effects and domain alignment.
- Repair: Fix legitimate senders before moving the domain to enforcement.
- Enforce: Set p=quarantine or p=reject after the authorised mail flow is understood.
- Review: Record evidence, assign an owner and review DNS annually and after major email changes.
This illustrative record shows the required policy class and an aggregate reporting address. It is not a copy-and-paste production record. The final tags, reporting mailbox and policy choice must match the organisation's real mail flow.
Illustrative DMARC record for example.comDNS
Name: _dmarc.example.com Type: TXT Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=r; aspf=r
After publishing or changing the record, use the DMARC checker to confirm that DNS exposes the intended tags. Validation confirms syntax and publication, while aggregate report analysis confirms how real senders authenticate.
What DMARC reduces and what remains
DMARC enforcement reduces direct spoofing of the protected From domain. Receiving systems still make the final handling decision, so enforcement does not guarantee identical treatment at every destination.
Covered by DMARC
- Spoofing: Unauthorised use of the protected From domain.
- Visibility: Aggregate data about observed sending sources.
Still needs other controls
- Lookalikes: Similar domains registered and used by another party.
- Compromise: Malicious mail sent through an authenticated account.
DMARC therefore belongs inside a wider email security process. It does not stop every phishing message, and passing authentication does not prove that message content is safe.
Monitoring, ownership and evidence
Annual DNS reviews and reviews after major email system changes are continuing Gold requirements: the same wording appears in the 2026 and 2027 excerpts. Teams should retain a sender inventory, approved DNS changes, report findings and remediation notes so the configuration has clear ownership. More frequent monitoring is our operational recommendation.
For SMBs and MSPs managing these controls across domains, Suped provides DMARC monitoring. Suped is our platform. It combines DMARC, SPF and DKIM monitoring with issue diagnosis, real-time alerts, blocklist monitoring and deliverability context. Its multi-tenant dashboard gives MSPs one place to manage client domains.
Suped also supports managed policy changes through Hosted DMARC, including staged configuration and continued report analysis. It can surface unrecognised sources and give steps to fix authentication issues. Suped does not certify organisations, guarantee certification or determine what an assessor will accept.
What SMBs and MSPs should do now
For Silver, check that every sending domain has correctly managed SPF or DKIM. For Gold, assess DMARC alignment using the revised SPF-or-DKIM condition, while retaining the separate SPF, DKIM and DMARC configuration requirements. A message with valid, aligned DKIM does not need aligned SPF as well. Continue enforcement, reporting and annual or post-change DNS reviews, and resolve legitimate authentication failures before tightening policy.
