ASD ISM 1799 Enforce email rejection for failed DMARC checks
What it says
Incoming emails are rejected if they do not pass DMARC checks.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEmails not verified by DMARC are blocked to enhance email security.
This control makes sure that emails failing to verify through DMARC checks are blocked. It's important because it keeps potentially dangerous or fraudulent emails out of your inbox, protecting your business from phishing attacks or scams that could lead to data loss or financial harm.
Free. Save your status, tasks and notes.
Why it matters
If emails that fail DMARC are not rejected, spoofed messages can reach users, increasing phishing and the likelihood of credential theft or fraud.
How to implement
The IT team should configure the email server to enforce DMARC checks.
This means setting up the server so that it automatically checks incoming emails against DMARC standards before allowing them through to the recipient.
Managers in charge of communications should train staff on recognising legitimate email failures.
Once DMARC is set up, if someone expects an email and it hasn't arrived, they should verify it was sent from a legitimate address and wasn't blocked by the filter unnecessarily.
System administrators should regularly update DMARC policies.
They need to stay informed about the latest DMARC standards and ensure their email server settings reflect any changes to keep security measures current.
The IT team should monitor and review email logs periodically.
Check the logs to identify any patterns or regular incidents of email rejection, ensuring legitimate emails aren't being blocked.
Business owners should coordinate with their email service provider to ensure DMARC settings are enabled and robust.
They should confirm that the service provider supports DMARC and that the required configurations are in place.
Keep it running
Review DMARC aggregate reports and adjust SPF/DKIM alignment so valid senders pass; keep the DMARC policy at reject to block spoofed mail.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The email server configuration document: Request to see documentation that details how DMARC checks are set up.
Look at
The specific DMARC settings and any integration with existing email platforms.
Good evidence
Includes evidence that settings align with security policies and reject emails which fail checks.
- Check 2 of 5What an auditor asks for
Ask for
The latest email system training logs: Verify if staff have undergone training related to DMARC and email safety.
Look at
The dates and contents of the training sessions.
Good evidence
Includes recent, comprehensive training that focuses on recognising issues stemming from DMARC rejections.
- Check 3 of 5What an auditor asks for
Ask for
To see the DMARC policy records: Request the policy documentation stating how emails are handled when they fail DMARC checks.
Look at
The policy date and enforcement details.
Good evidence
Shows a current, enforced policy designed to reject failing emails for security.
- Check 4 of 5What an auditor asks for
Ask for
Access to recent email log reports: View a sample of logs detailing rejected emails due to DMARC failures.
Look at
Frequency and patterns in these logs.
Good evidence
Is logs displaying legitimate and expected rejections with minimal false positives.
- Check 5 of 5What an auditor asks for
Ask for
Evidence of coordination with email service providers: Request any email communication or agreements regarding DMARC implementation.
Look at
Provider commitments to support DMARC on their platform.
Good evidence
Includes correspondence affirming DMARC compliance support.
Mappings
Closest match in ISO/IEC 27001: A.5.14, Information transfer policies and procedures, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets A.5.14.
ISM-1799 requires incoming emails that fail DMARC checks to be rejected, blocking messages that spoof a sender's domain. This is a specific sender authentication control for electronic messaging, which is one of the transfer facilities that Annex A 5.14 requires the organisation to govern with rules and procedures. Annex A 5.14 covers all forms of information transfer and related agreements with other parties, while ISM-1799 addresses only inbound email authentication enforcement.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.