Why do you need DMARC to protect your email domains from being leveraged in phishing attacks? To get the full picture, let's look at the basics—and how DMARC came to be.
This post originally appeared on the Armadillo Blog and has been lightly edited for clarity.
Most organisations have been successful in blocking malicious emails targeted at their employees, at least to some extent. Various on-premise and cloud providers exist to take care of anti-spam, anti-virus, reputation scores, and advanced features such as sandboxing of executables.
DMARC builds on two earlier email authentication standards: SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail).
As we mentioned in the first post of this series, with the arrival of ARC, one of the biggest blockers to DMARC adoption up to now has been the inability to use it with mailing lists or forwarders.
John Wilson, Director, Sales Engineering
Before the excitement that is creating a new SPF record, there are a few steps you should take in order to organize the information you will need to be successful.
Here is your “grocery” list of information you should know about your sending outgoing mail traffic:
- web server
- in-office mail server (e.g., Microsoft Exchange)
- your ISP's mail server
- mail server of your end users' home ISP
- any other mail server
This is the second in a new ongoing series for us that gives you the tips and tricks you need for successful DMARC deployment . Read the previous tip here.
What are the differences between DomainKeys (DK) and DKIM?
Pagination
- Page 1
- Next page