ASD ISM 1540 Configuring DMARC for email security
What it says
DMARC records are configured for an organisation's domains (including subdomains) such that 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 EnglishEnsure emails from your domains are legitimate by rejecting ones that fail DMARC checks.
Configuring DMARC for your organisation's emails ensures that only legitimate emails from your domain reach other people's inboxes. This is important because if unverified or fake emails aren't stopped, they could damage your reputation, expose your customers to scams, and result in financial losses.
Free. Save your status, tasks and notes.
Why it matters
If DMARC is not enforced, spoofed emails can bypass checks, enabling phishing, reputational harm and financial loss.
How to implement
The IT team should start by identifying all domain names used by the organisation for sending emails.
Make a list of each domain, including any subdomains like sales.yourcompany.com, used for email communications.
Once the domains are listed, an IT team member should create a DMARC policy.
Use an online generator to specify actions for emails that fail the DMARC check, such as reject. Ensure this policy is clear and suits the organisation's communication needs.
Network managers should publish the DMARC policy to the Domain Name System (DNS).
This means adding a special record to the DNS settings that corresponds with the DMARC policy created previously.
Designate a staff member to regularly check the DMARC reports.
This person should review email performance reports, which can be sent daily or weekly, to identify and rectify any issues with email delivery or potential spoofing attempts.
The IT department should provide training to the rest of the organisation about recognising phishing attempts.
While DMARC helps prevent fake emails, human awareness strengthens security by ensuring suspicious emails are flagged.
Keep it running
Review DMARC aggregate reports, validate SPF/DKIM alignment, and tighten policy to quarantine/reject for all subdomains.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The DMARC policy document: Request evidence of the policy detailing actions for failing emails.
Look at
The specific rules for how incoming emails from the domain are handled.
Good evidence
A clear policy document specifying actions like 'reject' or 'quarantine' for non-compliant emails.
- Check 2 of 5What an auditor asks for
Ask for
To see the DNS record settings: Request a printout or screengrab showing DNS settings including the DMARC record.
Look at
Details confirming the DMARC record is active with correct syntax.
Good evidence
A DNS record listing with the DMARC information visible and accurate.
- Check 3 of 5What an auditor asks for
Ask for
Recent DMARC reports: Request the latest DMARC aggregate reports.
Look at
The volume of emails passing and failing the checks.
Good evidence
Regular reports showing a majority of compliance with clear details on any issues.
- Check 4 of 5What an auditor asks for
Ask for
About the process for updating and reviewing DMARC records: Request details on who updates the DMARC records and how often this is done.
Look at
A documented process or regular review schedule.
Good evidence
A defined process indicating who checks the DMARC and how updates are applied.
- Check 5 of 5What an auditor asks for
Ask for
Employee training records: Request documentation of any training sessions conducted about email security.
Look at
Attendance records and training materials.
Good evidence
Evidence of regular training sessions that include information on recognising email scams.
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-1540 requires DMARC records to be published for an organisation's domains and subdomains with a policy that rejects emails failing DMARC checks, preventing others from sending email that impersonates the organisation. This is a specific technical control for the security of information transfer by electronic messaging, which Annex A 5.14 requires the organisation to govern through transfer rules, procedures or agreements. Annex A 5.14 covers all transfer facilities and parties, whereas ISM-1540 addresses only sender authentication policy for email domains.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.