Tag Archives: email security

Amazon SES – How to set up EasyDKIM for a new domain

Post Syndicated from Vinay Ujjini original https://aws.amazon.com/blogs/messaging-and-targeting/amazon-ses-how-to-set-up-easydkim-for-a-new-domain/

What is email authentication and why is it important?

Amazon Simple Email Service (SES) lets you reach customers confidently without an on-premises Simple Mail Transfer Protocol (SMTP) system. Amazon SES provides built-in support for email authentication protocols, including DKIM, SPF, and DMARC, which help improve the deliverability and authenticity of outgoing emails.

Email authentication is the process of verifying the authenticity of an email message to ensure that it is sent from a legitimate source and has not been tampered with during transmission. Email authentication methods use cryptographic techniques to add digital signatures or authentication headers to outgoing emails, which can be verified by email receivers to confirm the legitimacy of the email.

Email authentication helps establish a sender’s reputation as a trusted sender. Additionally, when email receivers can verify that emails are legitimately sent from a sender’s domain using authentication methods, it also helps establish the sender’s reputation as a trusted sender. Email authentication involves one or more technical processes used by mail systems (sending and receiving) that make certain key information in an email message verifiable. Email authentication generates signals about the email, which can be utilized in decision-making processes related to spam filtering and other email handling tasks.

There are currently two widely used email authentication mechanisms – SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). They provide information that the receiving domain can use to verify that the sending of the message was authorized in some way by the sending domain. DKIM can also help determine that the content was not altered in transit. And the DMARC (Domain-based Message Authentication, Reporting and Conformance) protocol allows sending domains to publish verifiable policies that can help receiving domains decide how best to handle messages that fail authentication by SPF and DKIM.

Email authentication protocols:

  1. SPF (Sender Policy Framework): SPF is an email authentication protocol that checks which IP addresses are authorized to send mail on behalf of the originating domain. Domain owners use SPF to tell email providers which servers are allowed to send email from their domains. This is an email validation standard that’s designed to prevent email spoofing.
  2. DKIM (DomainKeys Identified Mail): DKIM is an email authentication protocol that allows a domain to attach its identifier to a message. This asserts some level of responsibility or involvement with the message. A sequence of messages signed with the same domain name is assumed to provide a reliable base of information about mail associated with the domain name’s owner, which may feed into an evaluation of the domain’s “reputation”. It uses public-key cryptography to sign an email with a private key. Recipient servers can then use a public key published to a domain’s DNS to verify that parts of the emails have not been modified during the transit.
  3. DMARC (Domain-based Message Authentication, Reporting and Conformance): is an email authentication protocol that uses Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) to detect email spoofing. In order to comply with DMARC, messages must be authenticated through either SPF or DKIM, or both.

Let us dive deep into DKIM in this blog. Amazon SES provides three options for signing your messages using a DKIM signature:

  1. Easy DKIM: To set up a sending identity so that Amazon SES generates a public-private key pair and automatically adds a DKIM signature to every message that you send from that identity.
  2. BYODKIM (Bring Your Own DKIM): To provide your own public-private key pair for so SES adds a DKIM signature to every message that you send from that identity, see Provide your own DKIM authentication token (BYODKIM) in Amazon SES.
  3. Manually add DKIM signature: To add your own DKIM signature to email that you send using the SendRawEmail API, see Manual DKIM signing in Amazon SES.

The purpose of EasyDKIM is to simplify the process of generating DKIM keys, adding DKIM signatures to outgoing emails, and managing DKIM settings, making it easier for users to implement DKIM authentication for their email messages. Using EasyDKIM, Amazon SES aims to improve email deliverability, prevent email fraud and phishing attacks, establish sender reputation, enhance brand reputation, and comply with industry regulations or legal requirements. EasyDKIM doubles as domain verification (simplification) and it eliminates the need for customers to worry about DKIM key rotation (managed automation). By automating and simplifying the DKIM process, EasyDKIM helps users ensure the integrity and authenticity of their email communications, while reducing the risk of fraudulent activities and improving the chances of emails being delivered to recipients’ inboxes.

Setting up Easy DKIM in Amazon SES:

When you set up Easy DKIM for a domain identity, Amazon SES automatically adds a 2048-bit DKIM signature to every email that you send from that identity. You can configure EasyDKIM by using the Amazon SES console, or by using the API.

The procedure in this section is streamlined to just show the steps necessary to configure Easy DKIM on a domain identity that you’ve already created. If you haven’t yet created a domain identity or you want to see all available options for customizing a domain identity, such as using a default configuration set, custom MAIL FROM domain, and tags, see Creating a domain identity. Part of creating an Easy DKIM domain identity is configuring its DKIM-based verification where you will have the choice to either accept the Amazon SES default of 2048 bits, or to override the default by selecting 1024 bits. Steps to set up easyDKIM for a verified identity:

  1. Sign in to the AWS Management Console and open the Amazon SES console at https://console.aws.amazon.com/ses/
  2. In the navigation pane, under Configuration, choose Verified identities.
  3. List of verified identities in SES console

    Verified identities

  4. In the list of identities, choose an identity where the Identity type is Domain.
  5. Under the Authentication tab, in the DomainKeys Identified Mail (DKIM) container, choose Edit.
  6. In the Advanced DKIM settings container, choose the Easy DKIM button in the Identity type field.
  7. Choose EasyDKIM as identity type; RSA_2048_BITT in DKIM signing key length; Check Enabled checkbox under DKIM signatures.

    DKIM settings

  8. In the DKIM signing key length field, choose either RSA_2048_BIT or RSA_1024_BIT.
  9. In the DKIM signatures field, check the Enabled box.
  10. Choose Save changes.
  11. After configuring your domain identity with Easy DKIM, you must complete the verification process with your DNS provider – proceed to Verifying a DKIM domain identity with your DNS provider and follow the DNS authentication procedures for Easy DKIM.


Email authentication, especially DKIM, is crucial in securing your emails, establishing sender reputation, and improving email deliverability. EasyDKIM provides a simplified and automated way to implement DKIM authentication. It removes the hassles of generating DKIM keys and managing settings, while additionally reducing risks and and enhancing sender authenticity. By following the steps outlined in this blog post, you can easily set up easyDKIM in Amazon SES and start using DKIM authentication for your email campaigns.

About the Author

Vinay Ujjini is an Amazon Pinpoint and Amazon Simple Email Service Worldwide Principal Specialist Solutions Architect at AWS. He has been solving customer’s omni-channel challenges for over 15 years. He is an avid sports enthusiast and in his spare time, enjoys playing tennis & cricket.

Stop brand impersonation with Cloudflare DMARC Management

Post Syndicated from Joao Sousa Botto original https://blog.cloudflare.com/dmarc-management/

Stop brand impersonation with Cloudflare DMARC Management

Stop brand impersonation with Cloudflare DMARC Management

At the end of 2021 Cloudflare launched Security Center, a unified solution that brings together our suite of security products and unique Internet intelligence. It enables security teams to quickly identify potential security risks and threats to their organizations, map their attack surface and mitigate these risks with just a few clicks. While Security Center initially focused on application security, we are now adding crucial zero trust insights to further enhance its capabilities.

When your brand is loved and trusted, customers and prospects are looking forward to the emails you send them. Now picture them receiving an email from you: it has your brand, the subject is exciting, it has a link to register for something unique — how can they resist that opportunity?

But what if that email didn’t come from you? What if clicking on that link is a scam that takes them down the path of fraud or identity theft? And what if they think you did it? The truth is, even security minded people occasionally fall for well crafted spoof emails.

That poses a risk to your business and reputation. A risk you don’t want to take – no one does. Brand impersonation is a significant problem for organizations globally, and that’s why we’ve built DMARC Management – available in Beta today.

With DMARC Management you have full insight on who is sending emails on your behalf. You can one-click approve each source that is a legitimate sender for your domain, and then set your DMARC policy to reject any emails sent from unapproved clients.

Stop brand impersonation with Cloudflare DMARC Management

When the survey platform your company uses is sending emails from your domain, there’s nothing to worry about – you configured it that way. But if an unknown mail service from a remote country is sending emails using your domain that can be quite scary, and something you’ll want to address. Let’s see how.

Anti-spoofing mechanisms

Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) and Domain-based Message Authentication Reporting and Conformance (DMARC) are three common email authentication methods. Together, they help prevent spammers, phishers, and other unauthorized parties from sending emails on behalf of a domain they do not own.

SPF is a way for a domain to list all the servers the company sends emails from. Think of it like a publicly available employee directory that helps someone to confirm if an employee works for an organization. SPF records list all the IP addresses of all the servers that are allowed to send emails from the domain.

DKIM enables domain owners to automatically “sign” emails from their domain. Specifically, DKIM uses public key cryptography:

  1. A DKIM record stores the domain’s public key, and mail servers receiving emails from the domain can check this record to obtain the public key.
  2. The private key is kept secret by the sender, who signs the email’s header with this key.
  3. Mail servers receiving the email can verify that the sender’s private key was used by applying the public key. This also guarantees that the email was not tampered with while in transit.

DMARC tells a receiving email server what to do after evaluating the SPF and DKIM results. A domain’s DMARC policy can be set in a variety of ways — it can instruct mail servers to quarantine emails that fail SPF or DKIM (or both), to reject such emails, or to deliver them.

It’s not trivial to configure and maintain SPF and DMARC, though. If your configuration is too strict, legitimate emails will be dropped or marked as spam. If it’s too relaxed, your domain might be misused for email spoofing. The proof is that these authentication mechanisms (SPF / DKIM / DMARC) have existed for over 10 years and still, there are still less than 6 million active DMARC records.

DMARC reports can help, and a full solution like DMARC Management reduces the burden of creating and maintaining a proper configuration.

DMARC reports

All DMARC-compliant mailbox providers support sending DMARC aggregated reports to an email address of your choice. Those reports list the services that have sent emails from your domain and the percentage of messages that passed DMARC, SPF and DKIM. They are extremely important because they give administrators the information they need to decide how to adjust their DMARC policies — for instance, that’s how administrators know if their legitimate emails are failing SPF and DKIM, or if a spammer is trying to send illegitimate emails.

Stop brand impersonation with Cloudflare DMARC Management

But beware, you probably don’t want to send DMARC reports to a human-monitored email address, as these come in fast and furious from virtually every email provider your organization sends messages to, and are delivered in XML format. Typically, administrators set up reports to be sent to a service like our DMARC Management, that boils them down to a more digestible form. Note: These reports do not contain personal identifiable information (PII).

DMARC Management automatically creates an email address for those reports to be sent to, and adds the corresponding RUA record to your Cloudflare DNS to announce to mailbox providers where to send reports to. And yes, if you’re curious, these email addresses are being created using Cloudflare Email Routing.

Note: Today, Cloudflare DNS is a requirement for DMARC Management. Cloudflare Area 1 customers will soon also be able to see DMARC reports even if they’re using third-party DNS services.

Stop brand impersonation with Cloudflare DMARC Management

As reports are received in this dedicated email address, they are processed by a Worker that extracts the relevant data, parses it and sends it over to our analytics solution. And you guessed again, that’s implemented using Email Workers. You can read more about the technical implementation here.

Taking action

Now that reports are coming in, you can review the data and take action.

Note: It may take up to 24 hours for mailbox providers to start sending reports and for these analytics to be available to you.

At the top of DMARC Management you have an at-a-glance view of the outbound security configuration for your domain, more specifically DMARC, DKIM, and SPF. DMARC Management will soon start reporting on inbound email security as well, which includes STARTTLS, MTA-STS, DANE, and TLS reporting.

Stop brand impersonation with Cloudflare DMARC Management

The middle section shows the email volume over time, with individual lines showing those that pass DMARC and those that fail.

Stop brand impersonation with Cloudflare DMARC Management

Below, you have additional details that include the number of email messages sent by each source (per the DMARC reports), and the corresponding DMARC, SPF and DKIM statistics. You can approve (that is, include in SPF) any of these sources by clicking on “…”, and you can easily spot applications that may not have DKIM correctly configured.

Stop brand impersonation with Cloudflare DMARC Management

Clicking on any source gives you the same DMARC, SPF and DKIM statistics per IP address of that source. This is how you identify if there’s an additional IP address you might need to include in your SPF record, for example.

Stop brand impersonation with Cloudflare DMARC Management

The ones that fail are the ones you’ll want to take action on, as they will need to either be approved (which technically means including in the SPF record) if legitimate, or stay unapproved and be rejected by the receiving server when the DMARC policy is configured with p=reject.

Getting to a DMARC reject policy is the goal, but you don’t want to apply such a restrictive policy until you have high confidence that all legitimate sending services are accounted for in SPF (and DKIM, if appropriate). That may take a few weeks, depending on the number of services you have sending messages from your domain, but with DMARC Management you will quickly grasp when you’re ready to go.

What else is needed

Once you have approved all your authorized email senders (sources) and configured DMARC to quarantine or reject, you should be confident that your brand and organization are much safer. From then on, keeping an eye on your approved sources list is a very lightweight operation that doesn’t take more than a few minutes per month from your team. Ideally, when new applications that send emails from your domain are deployed in your company, you would proactively include the corresponding IP addresses in your SPF record.

But even if you don’t, you will find new unapproved senders notices on your Security Center, under the Security Insights tab, alongside other important security issues you can review and manage.

Stop brand impersonation with Cloudflare DMARC Management

Or you can check the unapproved list on DMARC Management every few weeks.

Whenever you see a legitimate sender source show up as unapproved, you know what to do — click “…” and mark them as approved!

What’s coming next

DMARC Management takes email security to the next level, and this is only the beginning.

We’re excited to demonstrate our investments in features that provide customers even more insight into their security. Up next we’ll be connecting security analytics from Cloudflare’s Cloud Access Security Broker (CASB) into the Security Center.

Stop brand impersonation with Cloudflare DMARC Management

This product integration will provide customers a way to understand the status of their wider SaaS security at a glance. By surfacing the makeup of CASB Findings (or security issues identified in popular SaaS apps) by severity, health of the SaaS integration, and the number of hidden issues, IT and security administrators will have a way to understand the status of their wider security surface area from a single source.

Stay tuned for more news on CASB in Security Center. In the meantime you can join the waitlist for DMARC Management beta for free today and, if you haven’t yet, we recommend you also check out Cloudflare Area 1 and request a Phishing Risk Assessment to block phishing, spoof and spam emails from coming into your environment.

How we built DMARC Management using Cloudflare Workers

Post Syndicated from André Cruz original https://blog.cloudflare.com/how-we-built-dmarc-management/

How we built DMARC Management using Cloudflare Workers

What are DMARC reports

How we built DMARC Management using Cloudflare Workers

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It’s an email authentication protocol that helps protect against email phishing and spoofing.

When an email is sent, DMARC allows the domain owner to set up a DNS record that specifies which authentication methods, such as SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail), are used to verify the email’s authenticity. When the email fails these authentication checks DMARC instructs the recipient’s email provider on how to handle the message, either by quarantining it or rejecting it outright.

DMARC has become increasingly important in today’s Internet, where email phishing and spoofing attacks are becoming more sophisticated and prevalent. By implementing DMARC, domain owners can protect their brand and their customers from the negative impacts of these attacks, including loss of trust, reputation damage, and financial loss.

In addition to protecting against phishing and spoofing attacks, DMARC also provides reporting capabilities. Domain owners can receive reports on email authentication activity, including which messages passed and failed DMARC checks, as well as where these messages originated from.

DMARC management involves the configuration and maintenance of DMARC policies for a domain. Effective DMARC management requires ongoing monitoring and analysis of email authentication activity, as well as the ability to make adjustments and updates to DMARC policies as needed.

Some key components of effective DMARC management include:

  • Setting up DMARC policies: This involves configuring the domain’s DMARC record to specify the appropriate authentication methods and policies for handling messages that fail authentication checks. Here’s what a DMARC DNS record looks like:

v=DMARC1; p=reject; rua=mailto:[email protected]

This specifies that we are going to use DMARC version 1, our policy is to reject emails if they fail the DMARC checks, and the email address to which providers should send DMARC reports.

  • Monitoring email authentication activity: DMARC reports are an important tool for domain owners to ensure email security and deliverability, as well as compliance with industry standards and regulations. By regularly monitoring and analyzing DMARC reports, domain owners can identify email threats, optimize email campaigns, and improve overall email authentication.
  • Making adjustments as needed: Based on analysis of DMARC reports, domain owners may need to make adjustments to DMARC policies or authentication methods to ensure that email messages are properly authenticated and protected from phishing and spoofing attacks.
  • Working with email providers and third-party vendors: Effective DMARC management may require collaboration with email providers and third-party vendors to ensure that DMARC policies are being properly implemented and enforced.

Today we launched DMARC management. This is how we built it.

How we built it

As a leading provider of cloud-based security and performance solutions, we at Cloudflare take a specific approach to test our products. We “dogfood” our own tools and services, which means we use them to run our business. This helps us identify any issues or bugs before they affect our customers.

We use our own products internally, such as Cloudflare Workers, a serverless platform that allows developers to run their code on our global network. Since its launch in 2017, the Workers ecosystem has grown significantly. Today, there are thousands of developers building and deploying applications on the platform. The power of the Workers ecosystem lies in its ability to enable developers to build sophisticated applications that were previously impossible or impractical to run so close to clients. Workers can be used to build APIs, generate dynamic content, optimize images, perform real-time processing, and much more. The possibilities are virtually endless. We used Workers to power services like Radar 2.0, or software packages like Wildebeest.

Recently our Email Routing product joined forces with Workers, enabling processing incoming emails via Workers scripts. As the documentation states: “With Email Workers you can leverage the power of Cloudflare Workers to implement any logic you need to process your emails and create complex rules. These rules determine what happens when you receive an email.” Rules and verified addresses can all be configured via our API.

Here’s how a simple Email Worker looks like:

export default {
  async email(message, env, ctx) {
    const allowList = ["[email protected]", "[email protected]"];
    if (allowList.indexOf(message.headers.get("from")) == -1) {
      message.setReject("Address not allowed");
    } else {
      await message.forward("[email protected]");

Pretty straightforward, right?

With the ability to programmatically process incoming emails in place, it seemed like the perfect way to handle incoming DMARC report emails in a scalable and efficient manner, letting Email Routing and Workers do the heavy lifting of receiving an unbound number of emails from across the globe. A high level description of what we needed is:

  1. Receive email and extract report
  2. Publish relevant details to analytics platform
  3. Store the raw report

Email Workers enable us to do #1 easily. We just need to create a worker with an email() handler. This handler will receive the SMTP envelope elements, a pre-parsed version of the email headers, and a stream to read the entire raw email.

For #2 we can also look into the Workers platform, and we will find the Workers Analytics Engine. We just need to define an appropriate schema, which depends both on what’s present in the reports and the queries we plan to do later. Afterwards we can query the data using either the GraphQL or SQL API.

For #3 we don’t need to look further than our R2 object storage. It is trivial to access R2 from a Worker. After extracting the reports from the email we will store them in R2 for posterity.

We built this as a managed service that you can enable on your zone, and added a dashboard interface for convenience, but in reality all the tools are available for you to deploy your own DMARC reports processor on top of Cloudflare Workers, in your own account, without having to worry about servers, scalability or performance.


How we built DMARC Management using Cloudflare Workers

Email Workers is a feature of our Email Routing product. The Email Routing component runs in all our nodes, so any one of them is able to process incoming mail, which is important because we announce the Email ingress BGP prefix from all our datacenters. Sending emails to an Email Worker is as easy as setting a rule in the Email Routing dashboard.

How we built DMARC Management using Cloudflare Workers

When the Email Routing component receives an email that matches a rule to be delivered to a Worker, it will contact our internal version of the recently open-sourced workerd runtime, which also runs on all nodes. The RPC schema that governs this interaction is defined in a Capnproto schema, and allows the body of the email to be streamed to Edgeworker as it’s read. If the worker script decides to forward this email, Edgeworker will contact Email Routing using a capability sent in the original request.

jsg::Promise<void> ForwardableEmailMessage::forward(kj::String rcptTo, jsg::Optional<jsg::Ref<Headers>> maybeHeaders) {
  auto req = emailFwdr->forwardEmailRequest();

  auto sendP = req.send().then(
      [](capnp::Response<rpc::EmailMetadata::EmailFwdr::ForwardEmailResults> res) mutable {
    auto result = res.getResponse().getResult();
    JSG_REQUIRE(result.isOk(), Error, result.getError());
  auto& context = IoContext::current();
  return context.awaitIo(kj::mv(sendP));

In the context of DMARC reports this is how we handle the incoming emails:

  1. Fetch the recipient of the email being processed, this is the RUA that was used. RUA is a DMARC configuration parameter that indicates where aggregate DMARC processing feedback should be reported pertaining to a certain domain. This recipient can be found in the “to” attribute of the message.
const ruaID = message.to
  1. Since we handle DMARC reports for an unbounded number of domains, we use Workers KV to store some information about each one and key this information on the RUA. This also lets us know if we should be receiving these reports.
const accountInfoRaw = await env.KV_DMARC_REPORTS.get(dmarc:${ruaID})
  1. At this point, we want to read the entire email into an arrayBuffer in order to parse it. Depending on the size of the report we may run into the limits of the free Workers plan. If this happens, we recommend that you switch to the Workers Unbound resource model which does not have this issue.
const rawEmail = new Response(message.raw)
const arrayBuffer = await rawEmail.arrayBuffer()
  1. Parsing the raw email involves, among other things, parsing its MIME parts. There are multiple libraries available that allow one to do this. For example, you could use postal-mime:
const parser = new PostalMime.default()
const email = await parser.parse(arrayBuffer)
  1. Having parsed the email we now have access to its attachments. These attachments are the DMARC reports themselves and they can be compressed. The first thing we want to do is store them in their compressed form in R2 for long-term storage. They can be useful later on for re-processing or investigating interesting reports. Doing this is as simple as calling put() on the R2 binding. In order to facilitate retrieval later we recommend that you spread the report files across directories based on the current time.
await env.R2_DMARC_REPORTS.put(
    `${date.getUTCFullYear()}/${date.getUTCMonth() + 1}/${attachment.filename}`,
  1. We now need to look into the attachment mime type. The raw form of DMARC reports is XML, but they can be compressed. In this case we need to decompress them first. DMARC reporter files can use multiple compression algorithms. We use the MIME type to know which one to use. For Zlib compressed reports pako can be used while for ZIP compressed reports unzipit is a good choice.

  2. Having obtained the raw XML form of the report, fast-xml-parser has worked well for us in parsing them. Here’s how the DMARC report XML looks:

    <[email protected]</email>
  1. We now have all the data in the report at our fingertips. What we do from here on depends a lot on how we want to present the data. For us, the goal was to display meaningful data extracted from them in our Dashboard. Therefore we needed an Analytics platform where we could push the enriched data. Enter, Workers Analytics Engine. The Analytics engine is perfect for this task since it allows us to send data to it from a worker, and exposes a GraphQL API to interact with the data afterwards. This is how we obtain the data to show in our dashboard.

In the future, we are also considering integrating Queues in the workflow to asynchronously process the report and avoid waiting for the client to complete it.

We managed to implement this project end-to-end relying only on the Workers infrastructure, proving that it’s possible, and advantageous, to build non-trivial apps without having to worry about scalability, performance, storage and security issues.

Open sourcing

As we mentioned before, we built a managed service that you can enable and use, and we will manage it for you. But, everything we did can also be deployed by you, in your account, so that you can manage your own DMARC reports. It’s easy, and free. To help you with that, we are releasing an open-source version of a Worker that processes DMARC reports in the way described above: https://github.com/cloudflare/dmarc-email-worker

If you don’t have a dashboard where to show the data, you can also query the Analytics Engine from a Worker. Or, if you want to store them in a relational database, then there’s D1 to the rescue. The possibilities are endless and we are excited to find out what you’ll build with these tools.

Please contribute, make your own, we’ll be listening.

Final words

We hope that this post has furthered your understanding of the Workers platform. Today Cloudflare takes advantage of this platform to build most of our services, and we think you should too.

Feel free to contribute to our open-source version and show us what you can do with it.

The Email Routing is also working on expanding the Email Workers API more functionally, but that deserves another blog soon.

Cloudflare partners with KnowBe4 to equip organizations with real-time security coaching to avoid phishing attacks

Post Syndicated from Ayush Kumar original https://blog.cloudflare.com/knowbe4-emailsecurity-integration/

Cloudflare partners with KnowBe4 to equip organizations with real-time security coaching to avoid phishing attacks

Cloudflare partners with KnowBe4 to equip organizations with real-time security coaching to avoid phishing attacks

Today, we are very excited to announce that Cloudflare’s cloud email security solution, Area 1, now integrates with KnowBe4, a leading security awareness training and simulated phishing platform. This integration allows mutual customers to offer real-time coaching to their employees when a phishing campaign is detected by Cloudflare’s email security solution.

We are all aware that phishing attacks often use email as a vector to deliver the fraudulent message. Cybercriminals use a range of tactics, such as posing as a trustworthy organization, using urgent or threatening language, or creating a sense of urgency to entice the recipient to click on a link or download an attachment.

Despite the increasing sophistication of these attacks and the solutions to stop them, human error remains the weakest link in this chain of events. This is because humans can be easily manipulated or deceived, especially when they are distracted or rushed. For example, an employee might accidentally click on a link in an email that looks legitimate but is actually a phishing attempt, or they might enter their password into a fake login page without realizing it. According to the 2021 Verizon Data Breach Investigations Report, phishing was the most common form of social engineering attack, accounting for 36% of all breaches. The report also noted that 85% of all breaches involved a human element, such as human error or social engineering.

Therefore, it is essential to educate and train individuals on how to recognize and avoid phishing attacks. This includes raising awareness of common phishing tactics and training individuals to scrutinize emails carefully before clicking on any links or downloading attachments.

Area1 integrates with KnowBe4

Our integration allows for the seamless integration of Cloudflare’s advanced email security capabilities with KnowBe4’s Security Awareness Training platform, KSMAT, and its real-time coaching product, SecurityCoach. This means that organizations using both products can now benefit from an added layer of security that detects and prevents email-based threats in real-time while also training employees to recognize and avoid such threats.

Organizations can offer real-time security coaching to their employees whenever our email security solution detects four types of events: malicious attachments, malicious links, spoofed emails, and suspicious emails. IT or security professionals can configure their real-time coaching campaigns to immediately deliver relevant training to their users related to a detected event.

“KnowBe4 is proud to partner with Cloudflare to provide a seamless integration with our new SecurityCoach product, which aims to deliver real-time security coaching and advice to help end users enhance their cybersecurity knowledge and strengthen their role in contributing to a strong security culture. KnowBe4 is actively working with Cloudflare to provide an API-based integration to connect our platform with systems that IT/security professionals already utilize, making rolling out new products to their teams an easy and unified process.”
Stu Sjouwerman, CEO, KnowBe4

By using the integration, organizations can ensure that their employees are not only protected by advanced security technology that detects and blocks malicious emails, but are also educated on how to identify and avoid these threats. This has been a commonly demanded feature from our customers and we have made it simple for them to implement it.

How it works

Create private key and public key in the Area 1 dashboard

Before you can set up this integration in your KnowBe4 (KMSAT) console, you will need to create a private key and public key with Cloudflare.

  • Log in to your Cloudflare Area 1 email security console as an admin.
  • Click the gear icon in the top-right corner of the page, and then navigate to the Service Accounts tab.
Cloudflare partners with KnowBe4 to equip organizations with real-time security coaching to avoid phishing attacks
  • Click + Add Service Account.
Cloudflare partners with KnowBe4 to equip organizations with real-time security coaching to avoid phishing attacks
  • In the NAME field, enter a name for your new service account.
Cloudflare partners with KnowBe4 to equip organizations with real-time security coaching to avoid phishing attacks
  • Click + Create Service Account.
  • In the pop-up window that opens, copy and save the private key somewhere that you can easily access. You will need this key to complete the setup process in the Set Up the Integration in your KnowBe4 (KMSAT) Console section below.
Cloudflare partners with KnowBe4 to equip organizations with real-time security coaching to avoid phishing attacks

Set up the integration in your KnowBe4 (KMSAT) Console

Once you have created a private key and public key in your Cloudflare Area 1 email security console, you can set up the integration in your KMSAT console. To register Cloudflare Area 1 email security with SecurityCoach in your KMSAT console, follow the steps below:

  • Log in to your KMSAT console and navigate to SecurityCoach > Setup > Security Vendor Integrations.
  • Locate Cloudflare Area 1 Email Security and click Configure.
Cloudflare partners with KnowBe4 to equip organizations with real-time security coaching to avoid phishing attacks
  • Enter the Public Key and Private Key that you saved in the ‘Create your private Key and public key’ section above.
Cloudflare partners with KnowBe4 to equip organizations with real-time security coaching to avoid phishing attacks
  • Click authorize. Once you’ve successfully authorized this integration, you can manage detection rules for Cloudflare Area 1 on the ‘Detection rules subtab’ of SecurityCoach.

SecurityCoach in action

Now that the SecurityCoach is set up, users within your organization will receive messages if Area 1 finds that a malicious email was sent to them. An example one can be seen below.

Cloudflare partners with KnowBe4 to equip organizations with real-time security coaching to avoid phishing attacks

This message not only alerts the user to be more scrutinous about emails they are receiving, since they now know they are being actively targeted, but also provides them with followup steps that they can take to ensure their account is as safe as possible. The image and text that shows up in the email can be configured from the KnowBe4 console giving customers full flexibility on what to communicate with their employees.

Cloudflare partners with KnowBe4 to equip organizations with real-time security coaching to avoid phishing attacks

What’s next

We’ll be expanding this integration with KnowBe4 to our other Zero Trust products in the coming months. If you have any questions or feedback on this integration, please contact your account team at Cloudflare. We’re excited to continue closely working with technology partners to expand existing and create new integrations that help customers on their Zero Trust journey.

Three ways to boost your email security and brand reputation with AWS

Post Syndicated from Michael Davie original https://aws.amazon.com/blogs/security/three-ways-to-boost-your-email-security-and-brand-reputation-with-aws/

If you own a domain that you use for email, you want to maintain the reputation and goodwill of your domain’s brand. Several industry-standard mechanisms can help prevent your domain from being used as part of a phishing attack. In this post, we’ll show you how to deploy three of these mechanisms, which visually authenticate emails sent from your domain to users and verify that emails are encrypted in transit. It can take as little as 15 minutes to deploy these mechanisms on Amazon Web Services (AWS), and the result can help to provide immediate and long-term improvements to your organization’s email security.

Phishing through email remains one of the most common ways that bad actors try to compromise computer systems. Incidents of phishing and related crimes far outnumber the incidents of other categories of internet crime, according to the most recent FBI Internet Crime Report. Phishing has consistently led to large annual financial losses in the US and globally.

Overview of BIMI, MTA-STS, and TLS reporting

An earlier post has covered how you can use Amazon Simple Email Service (Amazon SES) to send emails that align with best practices, including the IETF internet standards: Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC). This post will show you how to build on this foundation and configure your domains to align with additional email security standards, including the following:

  • Brand Indicators for Message Identification (BIMI) – This standard allows you to associate a logo with your email domain, which some email clients will display to users in their inbox. Visit the BIMI Group’s Where is my BIMI Logo Displayed? webpage to see how logos are displayed in the user interfaces of BIMI-supporting mailbox providers; Figure 1 shows a mock-up of a typical layout that contains a logo.
  • Mail Transfer Agent Strict Transport Security (MTA-STS) – This standard helps ensure that email servers always use TLS encryption and certificate-based authentication when they send messages to your domain, to protect the confidentiality and integrity of email in transit.
  • SMTP TLS reporting – This reporting allows you to receive reports and monitor your domain’s TLS security posture, identify problems, and learn about attacks that might be occurring.
Figure 1: A mock-up of how BIMI enables branded logos to be displayed in email user interfaces

Figure 1: A mock-up of how BIMI enables branded logos to be displayed in email user interfaces

These three standards require your Domain Name System (DNS) to publish specific records, for example by using Amazon Route 53, that point to web pages that have additional information. You can host this information without having to maintain a web server by storing it in Amazon Simple Storage Service (Amazon S3) and delivering it through Amazon CloudFront, secured with a certificate provisioned from AWS Certificate Manager (ACM).

Note: This AWS solution works for DKIM, BIMI, and DMARC, regardless of what you use to serve the actual email for your domains, which services you use to send email, and where you host DNS. For purposes of clarity, this post assumes that you are using Route 53 for DNS. If you use a different DNS hosting provider, you will manually configure DNS records in your existing hosting provider.

Solution architecture

The architecture for this solution is depicted in Figure 2.

Figure 2: The architecture diagram showing how the solution components interact

Figure 2: The architecture diagram showing how the solution components interact

The interaction points are as follows:

  1. The web content is stored in an S3 bucket, and CloudFront has access to this bucket through an origin access identity, a mechanism of AWS Identity and Access Management (IAM).
  2. As described in more detail in the BIMI section of this blog post, the Verified Mark Certificate is obtained from a BIMI-qualified certificate authority and stored in the S3 bucket.
  3. When an external email system receives a message claiming to be from your domain, it looks up BIMI records for your domain in DNS. As depicted in the diagram, a DNS request is sent to Route 53.
  4. To retrieve the BIMI logo image and Verified Mark Certificate, the external email system will make HTTPS requests to a URL published in the BIMI DNS record. In this solution, the URL points to the CloudFront distribution, which has a TLS certificate provisioned with ACM.

A few important warnings

Email is a complex system of interoperating technologies. It is also brittle: a typo or a missing DNS record can make the difference between whether an email is delivered or not. Pay close attention to your email server and the users of your email systems when implementing the solution in this blog post. The main indicator that something is wrong is the absence of email. Instead of seeing an error in your email server’s log, users will tell you that they’re expecting to receive an email from somewhere and it’s not arriving. Or they will tell you that they sent an email, and their recipient can’t find it.

The DNS uses a lot of caching and time-out values to improve its efficiency. That makes DNS records slow and a little unpredictable as they propagate across the internet. So keep in mind that as you monitor your systems, it can be hours or even more than a day before the DNS record changes have an effect that you can detect.

This solution uses AWS Cloud Development Kit (CDK) custom resources, which are supported by AWS Lambda functions that will be created as part of the deployment. These functions are configured to use CDK-selected runtimes, which will eventually pass out of support and require you to update them.


You will need permission in an AWS account to create and configure the following resources:

  • An Amazon S3 bucket to store the files and access logs
  • A CloudFront distribution to publicly deliver the files from the S3 bucket
  • A TLS certificate in ACM
  • An origin access identity in IAM that CloudFront will use to access files in Amazon S3
  • Lambda functions, IAM roles, and IAM policies created by CDK custom resources

You might also want to enable these optional services:

  • Amazon Route 53 for setting the necessary DNS records. If your domain is hosted by another DNS provider, you will set these DNS records manually.
  • Amazon SES or an Amazon WorkMail organization with a single mailbox. You can configure either service with a subdomain (for example, [email protected]) such that the existing domain is not disrupted, or you can create new email addresses by using your existing email mailbox provider.

BIMI has some additional requirements:

  • BIMI requires an email domain to have implemented a strong DMARC policy so that recipients can be confident in the authenticity of the branded logos. Your email domain must have a DMARC policy of p=quarantine or p=reject. Additionally, the domain’s policy cannot have sp=none or pct<100.

    Note: Do not adjust the DMARC policy of your domain without careful testing, because this can disrupt mail delivery.

  • You must have your brand’s logo in Scaled Vector Graphics (SVG) format that conforms to the BIMI standard. For more information, see Creating BIMI SVG Logo Files on the BIMI Group website.
  • Purchase a Verified Mark Certificate (VMC) issued by a third-party certificate authority. This certificate attests that the logo, organization, and domain are associated with each other, based on a legal trademark registration. Many email hosting providers require this additional certificate before they will show your branded logo to their users. Others do not currently support BIMI, and others might have alternative mechanisms to determine whether to show your logo. For more information about purchasing a Verified Mark Certificate, see the BIMI Group website.

    Note: If you are not ready to purchase a VMC, you can deploy this solution and validate that BIMI is correctly configured for your domain, but your branded logo will not display to recipients at major email providers.

What gets deployed in this solution?

This solution deploys the DNS records and supporting files that are required to implement BIMI, MTA-STS, and SMTP TLS reporting for an email domain. We’ll look at the deployment in more detail in the following sections.


BIMI is described by the Internet Engineering Task Force (IETF) as follows:

Brand Indicators for Message Identification (BIMI) permits Domain Owners to coordinate with Mail User Agents (MUAs) to display brand-specific Indicators next to properly authenticated messages. There are two aspects of BIMI coordination: a scalable mechanism for Domain Owners to publish their desired Indicators, and a mechanism for Mail Transfer Agents (MTAs) to verify the authenticity of the Indicator. This document specifies how Domain Owners communicate their desired Indicators through the BIMI Assertion Record in DNS and how that record is to be interpreted by MTAs and MUAs. MUAs and mail-receiving organizations are free to define their own policies for making use of BIMI data and for Indicator display as they see fit.

If your organization has a trademark-protected logo, you can set up BIMI to have that logo displayed to recipients in their email inboxes. This can have a positive impact on your brand and indicates to end users that your email is more trustworthy. The BIMI Group shows examples of how brand logos are displayed in user inboxes, as well as a list of known email service providers that support the display of BIMI logos.

As a domain owner, you can implement BIMI by publishing the relevant DNS records and hosting the relevant files. To have your logo displayed by most email hosting providers, you will need to purchase a Verified Mark Certificate from a BIMI-qualified certificate authority.

This solution will deploy a valid BIMI record in Route 53 (or tell you what to publish in the DNS if you’re not using Route 53) and will store your provided SVG logo and Verified Mark Certificate files in Amazon S3, to be delivered through CloudFront with a valid TLS certificate from ACM.

To support BIMI, the solution makes the following changes to your resources:

  1. A DNS record of type TXT is published at the following host:
    default._bimi.<your-domain>. The value of this record is: v=BIMI1; l=<url-of-your-logo> a=<url-of-verified-mark-certificate>. The value of <your-domain> refers to the domain that is used in the From header of messages that your organization sends.
  2. The logo and optional Verified Mark Certificate are hosted publicly at the HTTPS locations defined by <url-of-your-logo> and <url-of-verified-mark-certificate>, respectively.


MTA-STS is described by the IETF in RFC 8461 as follows:

SMTP (Simple Mail Transport Protocol) MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate.

Put simply, MTA-STS helps ensure that email servers always use encryption and certificate-based authentication when sending email to your domains, so that message integrity and confidentiality are preserved while in transit across the internet. MTA-STS also helps to ensure that messages are only sent to authorized servers.

This solution will deploy a valid MTA-STS policy record in Route 53 (or tell you what value to publish in the DNS if you’re not using Route 53) and will create an MTA-STS policy document to be hosted on S3 and delivered through CloudFront with a valid TLS certificate from ACM.

To support MTA-STS, the solution makes the following changes to your resources:

  1. A DNS record of type TXT is published at the following host: _mta-sts.<your-domain>. The value of this record is: v=STSv1; id=<unique value used for cache invalidation>.
  2. The MTA-STS policy document is hosted at and obtained from the following location: https://mta-sts.<your-domain>/.well-known/mta-sts.txt.
  3. The value of <your-domain> in both cases is the domain that is used for routing inbound mail to your organization and is typically the same domain that is used in the From header of messages that your organization sends externally. Depending on the complexity of your organization, you might receive inbound mail for multiple domains, and you might choose to publish MTA-STS policies for each domain.

Is it ever bad to encrypt everything?

In the example MTA-STS policy file provided in the GitHub repository and explained later in this post, the MTA-STS policy mode is set to testing. This means that your email server is advertising its willingness to negotiate encrypted email connections, but it does not require TLS. Servers that want to send mail to you are allowed to connect and deliver mail even if there are problems in the TLS connection, as long as you’re in testing mode. You should expect reports when servers try to connect through TLS to your mail server and fail to do so.

Be fully prepared before you change the MTA-STS policy to enforce. After this policy is set to enforce, servers that follow the MTA-STS policy and that experience an enforceable TLS-related error when they try to connect to your mail server will not deliver mail to your mail server. This is a difficult situation to detect. You will simply stop receiving email from servers that comply with the policy. You might receive reports from them indicating what errors they encountered, but it is not guaranteed. Be sure that the email address you provide in SMTP TLS reporting (in the following section) is functional and monitored by people who can take action to fix issues. If you miss TLS failure reports, you probably won’t receive email. If the TLS certificate that you use on your email server expires, and your MTA-STS policy is set to enforce, this will become an urgent issue and will disrupt the flow of email until it is fixed.

SMTP TLS reporting

SMTP TLS reporting is described by the IETF in RFC 8460 as follows:

A number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents (MTAs), including STARTTLS, DNS-Based Authentication of Named Entities (DANE) TLSA, and MTA Strict Transport Security (MTA-STS). These protocols can fail due to misconfiguration or active attack, leading to undelivered messages or delivery over unencrypted or unauthenticated channels. This document describes a reporting mechanism and format by which sending systems can share statistics and specific information about potential failures with recipient domains. Recipient domains can then use this information to both detect potential attacks and diagnose unintentional misconfigurations.

As you gain the security benefits of MTA-STS, SMTP TLS reporting will allow you to receive reports from other internet email providers. These reports contain information that is valuable when monitoring your TLS security posture, identifying problems, and learning about attacks that might be occurring.

This solution will deploy a valid SMTP TLS reporting record on Route 53 (or provide you with the value to publish in the DNS if you are not using Route 53).

To support SMTP TLS reporting, the solution makes the following changes to your resources:

  1. A DNS record of type TXT is published at the following host: _smtp._tls.<your-domain>. The value of this record is: v=TLSRPTv1; rua=mailto:<report-receiver-email-address>
  2. The value of <report-receiver-email-address> might be an address in your domain or in a third-party provider. Automated systems that process these reports must be capable of processing GZIP compressed files and parsing JSON.

Deploy the solution with the AWS CDK

In this section, you’ll learn how to deploy the solution to create the previously described AWS resources in your account.

  1. Clone the following GitHub repository:

    git clone https://github.com/aws-samples/serverless-mail
    cd serverless-mail/email-security-records

  2. Edit CONFIG.py to reflect your desired settings, as follows:
    1. If no Verified Mark Certificate is provided, set VMC_FILENAME = None.
    2. If your DNS zone is not hosted on Route 53, or if you do not want this app to manage Route 53 DNS records, set ROUTE_53_HOSTED = False. In this case, you will need to set TLS_CERTIFICATE_ARN to the Amazon Resource Name (ARN) of a certificate hosted on ACM in us-east-1. This certificate is used by CloudFront and must support two subdomains: mta-sts and your configured BIMI_ASSET_SUBDOMAIN.
  3. Finalize the preparation, as follows:
    1. Place your BIMI logo and Verified Mark Certificate files in the assets folder.
    2. Create an MTA-STS policy file at assets/.well-known/mta-sts.txt to reflect your mail exchange (MX) servers and policy requirements. An example file is provided at assets/.well-known/mta-sts.txt.example
  4. Deploy the solution, as follows:
    1. Open a terminal in the email-security-records folder.
    2. (Recommended) Create and activate a virtual environment by running the following commands.
      python3 -m venv .venv
      source .venv/bin/activate
    3. Install the Python requirements in your environment with the following command.
      pip install -r requirements.txt
    4. Assume a role in the target account that has the permissions outlined in the Prerequisites section of this post.

      Using AWS CDK version 2.17.0 or later, deploy the bootstrap in the target account by running the following command. To learn more, see Bootstrapping in the AWS CDK Developer Guide.
      cdk bootstrap

    5. Run the following command to synthesize the CloudFormation template. Review the output of this command to verify what will be deployed.
      cdk synth
    6. Run the following command to deploy the CloudFormation template. You will be prompted to accept the IAM changes that will be applied to your account.
      cdk deploy

      Note: If you use Route53, these records are created and activated in your DNS zones as soon as the CDK finishes deploying. As the records propagate through the DNS, they will gradually start affecting the email in the affected domains.

    7. If you’re not using Route53 and instead are using a third-party DNS provider, create the CNAME and TXT records as indicated. In this case, your email is not affected by this solution until you create the records in DNS.

Testing and troubleshooting

After you have deployed the CDK solution, you can test it to confirm that the DNS records and web resources are published correctly.


  1. Query the BIMI DNS TXT record for your domain by using the dig or nslookup command in your terminal.

    dig +short TXT default._bimi.<your-domain.example>

    Verify the response. For example:

    "v=BIMI1; l=https://bimi-assets.<your-domain.example>/logo.svg"

  2. In your web browser, open the URL from that response (for example, https://bimi-assets.<your-domain.example>/logo.svg) to verify that the logo is available and that the HTTPS certificate is valid.
  3. The BIMI group provides a tool to validate your BIMI configuration. This tool will also validate your VMC if you have purchased one.


  1. Query the MTA-STS DNS TXT record for your domain.

    dig +short TXT _mta-sts.<your-domain.example>

    The value of this record is as follows:

    v=STSv1; id=<unique value used for cache invalidation>

  2. You can load the MTA-STS policy document using your web browser. For example, https://mta-sts.<your-domain.example>/.well-known/mta-sts.txt
  3. You can also use third party tools to examine your MTA-STS configuration, such as MX Toolbox.

TLS reporting

  1. Query the TLS reporting DNS TXT record for your domain.

    dig +short TXT _smtp._tls.<your-domain.example>

    Verify the response. For example:

    "v=TLSRPTv1; rua=mailto:<your email address>"

  2. You can also use third party tools to examine your TLS reporting configuration, such as Easy DMARC.

Depending on which domains you communicate with on the internet, you will begin to see TLS reports arriving at the email address that you have defined in the TLS reporting DNS record. We recommend that you closely examine the TLS reports, and use automated analytical techniques over an extended period of time before changing the default testing value of your domain’s MTA-STS policy. Not every email provider will send TLS reports, but examining the reports in aggregate will give you a good perspective for making changes to your MTA-STS policy.


To remove the resources created by this solution:

  1. Open a terminal in the cdk-email-security-records folder.
  2. Assume a role in the target account with permission to delete resources.
  3. Run cdk destroy.

Note: The asset and log buckets are automatically emptied and deleted by the cdk destroy command.


When external systems send email to or receive email from your domains they will now query your new DNS records and will look up your domain’s BIMI, MTA-STS, and TLS reporting information from your new CloudFront distribution. By adopting the email domain security mechanisms outlined in this post, you can improve the overall security posture of your email environment, as well as the perception of your brand.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

Want more AWS Security news? Follow us on Twitter.

Michael Davie

Michael Davie

Michael is a Senior Industry Specialist with AWS Security Assurance. He works with our customers, their regulators, and AWS teams to help raise the bar on secure cloud adoption and usage. Michael has over 20 years of experience working in the defence, intelligence, and technology sectors in Canada and is a licensed professional engineer.

Jesse Thompson

Jesse Thompson

Jesse is an Email Deliverability Manager with the Amazon Simple Email Service team. His background is in enterprise IT development and operations, with a focus on email abuse mitigation and encouragement of authenticity practices with open standard protocols. Jesse’s favorite activity outside of technology is recreational curling.

Expanding Area 1 email security to the Athenian Project

Post Syndicated from Jocelyn Woolbright original https://blog.cloudflare.com/expanding-area-1-email-security-to-the-athenian-project/

Expanding Area 1 email security to the Athenian Project

This post is also available in 简体中文, Deutsch, Français and Español.

Expanding Area 1 email security to the Athenian Project

Election security encompasses a wide variety of measures, including the protection of voting machines, election office networks, voter registration databases, and other systems that manage the electoral process. At Cloudflare, we have reported on threats to state and local governments under the Athenian Project, how we prepare political campaigns and state parties under Cloudflare for Campaigns for election season, and our work with organizations that report on election results and voting rights groups under Project Galileo.

Since the 2022 US midterm elections, we have been thinking about how we help state and local governments deflect larger cyber threats that target the election community and have been analyzing the biggest problems they are facing. In October 2022, Jen Easterly, the director of the Cybersecurity and Infrastructure Security Agency, said, “The current election threat environment is more complex than it has ever been.” Amid threats, intimidation toward election workers, and cyber attacks against election infrastructure and operations, preparing for elections is no easy task.

At Cloudflare, our mission is to help build a better Internet. The Internet plays a key role in promoting democracy and ensuring constituents’ access to information. With this, we are excited to share that we have grown our offering under the Athenian Project to include Cloudflare’s Area 1 email security suite to help state and local governments protect against a broad spectrum of phishing attacks to keep voter data safe and secure.

Our work in protecting elections

To understand why we have expanded our product set, we need to look back on how our services have helped state and local governments during election time. Under the Athenian Project, we have provided our highest level of Cloudflare services—the Enterprise plan—for free to state and governments that run elections. The idea originally was that, just like every other Internet property, election websites need to be fast, they need to be reliable, and they need to be secure. Yet, scarce budgets too often prevent governments from getting the right resources to prevent attacks and stay online.

With this, we launched the Athenian Project in 2017. It includes many of our core web services, such as DDoS protection, Web Application Firewall, SSL encryption, and more security features that focus on web applications. We have been able to provide these services to local governments in 31 states and currently protect 359 election entities in the United States.

We have expanded our product set at Cloudflare with Workers, Pages, Zero Trust, and network security solutions. With this, we wanted to understand how we can better support the election community that we work with every day on the Athenian Project.

We knew we could provide more

Internally, we brainstormed on the most pressing issues that face the election community and overall Internet ecosystem. We also asked new and existing Athenian participants on the largest pain points they have when it comes to securing their internal networks and applications. We received a range of answers, from fears of a DDoS attack on election night, to zero-day exploits, on-path attacks, and malware attacks. Many of the same themes came up, especially for small counties that run elections with a huge fear of phishing and ransomware attacks.

Despite email’s importance as a communication method, many types of email security still are not built into email by default. As a result, email is a major attack vector for organizations large and small, and for individual people as well. We have seen firsthand phishing attempts that take advantage of human psychology to encourage quick —and unfortunate— decision-making. Once an attacker has infiltrated a network, they can easily move laterally undetected and impact a wide range of sensitive internal systems.

That is why email security plays a critical role in preemptive defenses against ransomware attacks. Since many of these attacks start with a malicious or phishing email, effective email security can act as a frontline defense against ransomware, and stop these attacks before they reach inboxes. Due to the ease with which threats can be blocked before they reach an election official’s inbox, we were excited to work with those in the election space to find the best way to make these products available.

Typically, when we offer new security products under our Impact projects, we collaborate with external stakeholders. One example is the civil society groups that we partner with under Project Galileo; many of them work in the election community and at government agencies, such as CISA’s Joint Cyber Defense Collaborative (JCDC). These partnerships help us understand how to provide these security tools in a responsible and sustainable way.

How one North Carolina county uses Area 1 email security

Months before the 2022 US midterm elections, we reached out to a few state and local governments that currently use Zero Trust products, such as Access and Gateway, to discuss email security.

Expanding Area 1 email security to the Athenian Project

One of our Athenian participants that was eager to work with us on this expansion was Rowan County, North Carolina. For Randy Cress, CIO for Rowan County, election season means all hands on deck for IT staff in order to secure their .gov site that provides accurate, secure information to voters.

In 2020, Rowan County reported that Cloudflare helped them tackle a 400% increase in traffic on a limited budget which allowed them to refocus resources on other county initiatives. When it comes to phishing attacks, Randy wanted to shield county employees from phishing attacks and block malicious threats automatically.

Prior to Area 1 Security, we were using Office 365 email protection with limited insight for the specifics for messages that were quarantined. While cloud services from Microsoft are continually evolving, we were looking to reduce complexity to support security functions within our environment, allowing us to continue implementing new layers of defense.

Deploying Area 1 gave the county the ability to preemptively discover and eliminate phishing attacks before they inflict damage in their environment. Randy added, “Our team was able to fully onboard prior to the official onboarding call in less than 30 minutes with Cloudflare. We were able to focus on features and specifics of the product offering in lieu of time spent in configuration mode and troubleshooting. Since we are using Cloudflare for DNS and DDoS protection, the changes were extremely easy and there were no interruptions to our mail delivery process.”

For the 2022 US midterm elections, Randy reported, “Leading up to the elections, reports within our Area 1 dashboard indicated 2x as many inbound malicious emails from the same time period in October 2022. We saw credential harvesting as the top threat, and we are easily able to see which users are targeted for email compromise. With Area 1 Security under the Athenian Project, we were able to add additional layers of security to our organization, as it allowed us to preemptively defend against malicious messages before an employee can click on a malicious link. This gives us comfort knowing that Cloudflare is our first line of defense, so we can focus on providing a secure voting process for the constituents of Rowan County.”

Area 1 and the Athenian Project

Cloudflare Area 1 email security is a cloud-native service that stops phishing attacks and can be used with Enterprise accounts under the Athenian Project. If you are a state or local government that is interested in learning more about the Athenian Project, please apply on our website: https://www.cloudflare.com/athenian/.

How Cloudflare helps secure the inboxes of democracy

Post Syndicated from Ayush Kumar original https://blog.cloudflare.com/securing-the-inboxes-of-democracy/

How Cloudflare helps secure the inboxes of democracy

How Cloudflare helps secure the inboxes of democracy

We at Cloudflare believe that every candidate, no matter their political affiliation, should be able to operate their campaign without having to worry about the risk of cyberattacks. Malicious attackers such as nation-state threat actors, those seeking monetary reward, or those with too much time on their hands often disagree with our mission and aim to wreak havoc on the democratic process.

Protecting Email Inboxes Is Key In Stopping Attacks

In the past years, malicious actors have used email as their primary threat vector when trying to disrupt election campaigns. A quick search online shows how active attackers still are in trying to compromise election official’s email inboxes.1 Over 90% of damages done to any organization are caused by a phishing attack, making protecting email inboxes a key focus. A well crafted phishing email paired, or an errant click could give an attacker the opportunity to see sensitive information, disseminate false information to voters, or steal campaign donations.

For the United States 2022 midterm elections, Cloudflare protected the inboxes of over 100 campaigns, election officials and public organizations supporting elections. These campaigns ranged from new officials seeking spots in their local elections to incumbents in the national government. In the three months leading up to the recent elections, Cloudflare processed over 20 million emails and stopped around 150K phishing attacks from making their way into campaign officials’ email inboxes.

Political Campaigns Are Attacked Consistently

Some campaigns were targeted more than others. For example, the campaign of a specific incumbent seeking re-election in the US Senate saw their staff members receiving over 35 malicious emails on average every day. And attackers were not just phishing for credentials but also trying to impersonate officials. We saw over 10 thousand emails sent in the three-month span that were using the names of those running for office without their permission.

Below are the metrics we saw from a senator’s campaign who attackers frequently tried to phish.

How Cloudflare helps secure the inboxes of democracy

A candidate for the US House of Representatives saw their staff members receive an email with the subject “Staff Payroll Review” that asked them to access a document link.

Looking at the email, it would be tough to distinguish it from a valid internal email. It contained a valid email footer and branding that is consistent with the campaign. However, Area 1 models found several discrepancies within the metadata of the email and marked it as malicious.

Our models found that the domain sending these emails was suspicious based on how similar it was to the representative’s actual campaign email. We refer to this as domain proximity. Also analyzing the link found in the email found that it was recently registered, further adding suspicion to the validity of the email.

Taking in all the data points, Area 1 made sure that the email never made it to any campaign staff’s mailbox and prevented the loss of data and money.

How Cloudflare helps secure the inboxes of democracy

Another common attack campaigns see is the use of malicious attachments. These attachments can range from containing ransomware to data uploaders. The goal is to either slow down the politician’s campaign or exfiltrate sensitive information.

Attackers will use misdirection by either changing the extension of the attached file or by mentioning in the body of the email that the attachment is something more innocuous. We saw this in action for another campaign where a staffer was sent a targeted email asking them to download a purchase order.

Someone who processes hundreds of purchase orders a day does not have the time to thoroughly scrutinize every email and instead will focus on getting the money paid, so operations are not halted. Area 1’s models saved the staffer time and assessed this email to be malicious.

Our models first noticed that the attachment was a 7-Zip file called PO567.7z. Most purchase orders are sent via PDF so seeing it being sent as a 7z compressed file was concerning. Another data point the models assessed as being anomalous was the poor sentiment. The email not only has a glaring  grammatical mistake (i.e. “Dear Info,”) but also had poor message tone since it lacked common information found in legitimate purchase order emails.

How Cloudflare helps secure the inboxes of democracy

All these signals, combined with the fact that this is the first time the recipient has ever received communications from the sender, triggered Area 1 to stop the email from making it into any mailbox.

These examples speak about the trust that campaigns place in Cloudflare. Our ability to scan millions of emails and prevent dangerous ones from making it into mailboxes while allowing safe ones to reach their intended recipients with no interruptions is why so many campaigns chose Cloudflare’s Area 1 product to secure their mailboxes and by extension secure our democratic institutions.

Cloudflare’s Area 1 Solution

All this is possible because of Area 1’s preemptive campaign discovery and machine learning algorithms which analyze various threat signals, from email attachments, to the sender’s domain, to sentiment within the email itself in order to assess whether an email is malicious or not.

We also made Area 1 easily deployable, ensuring that campaigns are protected right away rather than having to spend time configuring hardware, agents, or appliances. Cloudflare also knows that election campaigns struggle to apply the appropriate email hygiene and authentication controls, stipulated by industry standards (such as SPF / DKIM / DMARC).

These can be complex and take time to implement. The rapid cycle of new campaigns makes it harder to set up the right email authentication controls that conform with industry best practices. Given that, it is all the more vital to ensure there are strong inbound technical controls against phishing and email-based attacks; letting campaigns focus on what’s most important – spreading their message to their constituents in the most effective & secure manner possible.
We know that those who seek to become political leaders have a target on their backs from attackers looking to disrupt the democratic process.

At Cloudflare, we believe in creating a better Internet and that means ensuring that inboxes remain secure. If you would like to learn more about how Area 1 works and other ways we protect email inboxes, please check out the Area 1 product page here.

1) https://www.cbsnews.com/feature/election-hacking/

Cloudflare Area 1 – how the best Email Security keeps getting better

Post Syndicated from Joao Sousa Botto original https://blog.cloudflare.com/email-security/

Cloudflare Area 1 - how the best Email Security keeps getting better

Cloudflare Area 1 - how the best Email Security keeps getting better

On February 23, 2022, after being a customer for two years and seeing phishing attacks virtually disappear from our employee’s mailboxes, Cloudflare announced the acquisition of Area 1 Security.

Thanks to its unique technology (more on that below) Cloudflare Area 1 can proactively identify and protect against phishing campaigns before they happen, and potentially prevent the 90%+ of all cyberattacks that Deloitte research identified as starting with an email. All with little to no impact on employee productivity.

But preventing 90% of the attacks is not enough, and that’s why Cloudflare Area 1 email security is part of our Zero Trust platform. Here’s what’s new.

Email Security on your Cloudflare Dashboard

Starting today you will find a dedicated Email Security section on your Cloudflare dashboard. That’s the easiest way for any Cloudflare customer to get familiar with and start using Cloudflare Area 1 Email Security.

From there you can easily request a trial, which gives you access to the full product for 30 days.

Our team will guide you through the setup, which will take just a few minutes. That’s the beauty of not having to install and tune a Secure Email Gateway (SEG). You can simply configure Area 1 inline or connect through the API, journaling, or other connectors – none of these options disrupt mail flow or the end user experience. And you don’t need any new hardware, appliances or agents.

Once the trial starts, you’ll be able to review detection metrics and forensics in real time, and will receive real-time updates from the Area 1 team on incidents that require immediate attention.

At the end of the trial you will also have a Phishing Risk Assessment where our team will walk you through the impact of the mitigated attacks and answer your questions.

Cloudflare Area 1 - how the best Email Security keeps getting better

Another option you’ll see on the Email Security section of the Cloudflare Dashboard is to explore the Area 1 demo.

At the click of a button you’ll enter the Area 1 portal of a fictitious company where you can see the product in action. You can interact with the full product, including our advanced message classifiers, the BEC protections, real time view of spoofed domains, and our unique message search and trace capabilities.

Cloudflare Area 1 - how the best Email Security keeps getting better

Product Expansions

Being cloud-native has allowed us to develop some unique capabilities. Most notably, we scan the Internet for attacker infrastructure, sources and delivery mechanisms to stop phishing attacks days before they hit an inbox. These are state of the art machine-learning models using the threat intelligence data that Area 1 has accumulated since it was founded nine years ago, and now they also incorporate data from the 124 billion cyber threats that Cloudflare blocks each day and its 1.7 trillion daily DNS queries.

Since the product is cloud-based and no local appliances are involved, these unique datasets and models benefit every customer immediately and apply to the full range of email attack types (URLs, payloads, BEC), vectors (email, web, network), and attack channels (external, internal, trusted partners). Additionally, the threat datasets, observables and Indicators of Compromise (IOC) are now additional signals to Cloudflare Gateway (part of Zero Trust), extending protection beyond email and giving Cloudflare customers the industry’s utmost protection against converged or blended threats.

The expertise Area 1 gained through this relentless focus on Threat Research and Threat Operations (i.e., disrupting actors once identified) is also leading to a new large scale initiative to make every Cloudflare customer, and the broader Internet, safer – Cloudforce One.

The Cloudforce One team is composed of analysts assigned to five subteams: Malware Analysis, Threat Analysis, Active Mitigation and Countermeasures, Intelligence Analysis, and Intelligence Sharing. Collectively, they have tracked many of the most sophisticated cyber criminals on the Internet while at the National Security Agency (NSA), USCYBERCOM, and Area 1 Security, and have worked closely with similar organizations and governments to disrupt these threat actors. They’ve also been prolific in publishing “finished intel” reports on security topics of significant geopolitical importance, such as targeted attacks against governments, technology companies, the energy sector, and law firms, and have regularly briefed top organizations around the world on their efforts.

The team will help protect all Cloudflare customers by working closely with our existing product, engineering, and security teams to improve our products based on tactics, techniques, and procedures (TTPs) observed in the wild. Customers will get better protection without having to take any action.

Additionally, customers can purchase a subscription to Cloudforce One (now generally available), and get access to threat data and briefings, dedicated security tools, and the ability to make requests for information (RFIs) to the team’s threat operations staff. RFIs can be on any security topic of interest, and will be analyzed and responded to in a timely manner. For example, the Cloudforce One Malware Analysis team can accept uploads of possible malware and provide a technical analysis of the submitted resource.

Lastly, SPF/DKIM/DMARC policies are another tool that can be used to prevent Email Spoofing and have always been a critical part of Area 1’s threat models. Cloudflare Area 1 customers receive weekly DMARC sender reports to understand the efficacy of their configuration, but customers have also asked for help in setting up SPF/DKIM/DMARC records for their own domains.

It was only logical to make Cloudflare’s Email Security DNS Wizard part of our Email Security stack to guide customers through their initial SPF, DKIM and DMARC configuration. The wizard is now available to all customers using Cloudflare DNS, and will soon be available to Cloudflare Area 1 customers using a third party DNS. Getting SPF/DKIM/DMARC right can be complex, but it is a necessary and vital part of making the Internet safer, and this solution will help you build a solid foundation.

You’ll be hearing from us very soon regarding more expansions to the Area 1 feature set. In the meantime, if you want to experience Area 1 first-hand sign up for a Phishing Risk Assessment here or explore the interactive demo through the Email section of your Cloudflare Dashboard.

Area 1 threat indicators now available in Cloudflare Zero Trust

Post Syndicated from Jesse Kipp original https://blog.cloudflare.com/phishing-threat-indicators-in-zero-trust/

Area 1 threat indicators now available in Cloudflare Zero Trust

Area 1 threat indicators now available in Cloudflare Zero Trust

Over the last several years, both Area 1 and Cloudflare built pipelines for ingesting threat indicator data, for use within our products. During the acquisition process we compared notes, and we discovered that the overlap of indicators between our two respective systems was smaller than we expected. This presented us with an opportunity: as one of our first tasks in bringing the two companies together, we have started bringing Area 1’s threat indicator data into the Cloudflare suite of products. This means that all the products today that use indicator data from Cloudflare’s own pipeline now get the benefit of Area 1’s data, too.

Area 1 threat indicators now available in Cloudflare Zero Trust

Area 1 built a data pipeline focused on identifying new and active phishing threats, which now supplements the Phishing category available today in Gateway. If you have a policy that references this category, you’re already benefiting from this additional threat coverage.

How Cloudflare identifies potential phishing threats

Cloudflare is able to combine the data, procedures and techniques developed independently by both the Cloudflare team and the Area 1 team prior to acquisition. Customers are able to benefit from the work of both teams across the suite of Cloudflare products.

Cloudflare curates a set of data feeds both from our own network traffic, OSINT sources, and numerous partnerships, and applies custom false positive control. Customers who rely on Cloudflare are spared the software development effort as well as the operational workload to distribute and update these feeds. Cloudflare handles this automatically, with updates happening as often as every minute.

Cloudflare is able to go beyond this and work to proactively identify phishing infrastructure in multiple ways. With the Area 1 acquisition, Cloudflare is now able to apply the adversary-focused threat research approach of Area1 across our network. A team of threat researchers track state-sponsored and financially motivated threat actors, newly disclosed CVEs, and current phishing trends.

Cloudflare now operates mail exchange servers for hundreds of organizations around the world, in addition to its DNS resolvers, Zero Trust suite, and network services. Each of these products generates data that is used to enhance the security of all of Cloudflare’s products. For example, as part of mail delivery, the mail engine performs domain lookups, scores potential phishing indicators via machine learning, and fetches URLs. Data which can now be used through Cloudflare’s offerings.

How Cloudflare Area 1 identifies potential phishing threats

The Cloudflare Area 1 team operates a suite of web crawling tools designed to identify phishing pages, capture phishing kits, and highlight attacker infrastructure. In addition, Cloudflare Area 1 threat models assess campaigns based on signals gathered from threat actor campaigns; and the associated IOCs of these campaign messages are further used to enrich Cloudflare Area 1 threat data for future campaign discovery. Together these techniques give Cloudflare Area 1 a leg up on identifying the indicators of compromise for an attacker prior to their attacks against our customers. As part of this proactive approach, Cloudflare Area 1 also houses a team of threat researchers that track state-sponsored and financially motivated threat actors, newly disclosed CVEs, and current phishing trends. Through this research, analysts regularly insert phishing indicators into an extensive indicator management system that may be used for our email product or any other product that may query it.

Cloudflare Area 1 also collects information about phishing threats during our normal operation as the mail exchange server for hundreds of organizations across the world. As part of that role, the mail engine performs domain lookups, scores potential phishing indicators via machine learning, and fetches URLs. For those emails found to be malicious, the indicators associated with the email are inserted into our indicator management system as part of a feedback loop for subsequent message evaluation.

How Cloudflare data will be used to improve phishing detection

In order to support Cloudflare products, including Gateway and Page Shield, Cloudflare has a data pipeline that ingests data from partnerships, OSINT sources, as well as threat intelligence generated in-house at Cloudflare. We are always working to curate a threat intelligence data set that is relevant to our customers and actionable in the products Cloudflare supports. This is our North star: what data can we provide that enhances our customer’s security without requiring our customers to manage the complexity of data, relationships, and configuration. We offer a variety of security threat categories, but some major focus areas include:

  • Malware distribution
  • Malware and Botnet Command & Control
  • Phishing,
  • New and newly seen domains

Phishing is a threat regardless of how the potential phishing link gets entry into an organization, whether via email, SMS, calendar invite or shared document, or other means. As such, detecting and blocking phishing domains has been an area of active development for Cloudflare’s threat data team since almost its inception.

Looking forward, we will be able to incorporate that work into Cloudflare Area 1’s phishing email detection process. Cloudflare’s list of phishing domains can help identify malicious email when those domains appear in the sender, delivery headers, message body or links of an email.

1+1 = 3: Greater dataset sharing between Cloudflare and Area 1

Threat actors have long had an unfair advantage — and that advantage is rooted in the knowledge of their target, and the time they have to set up specific campaigns against their targets. That dimension of time allows threat actors to set up the right infrastructure, perform reconnaissance, stage campaigns, perform test probes, observe their results, iterate, improve and then launch their ‘production’ campaigns. This precise element of time gives us the opportunity to discover, assess and proactively filter out campaign infrastructure prior to campaigns reaching critical mass. But to do that effectively, we need visibility and knowledge of threat activity across the public IP space.

With Cloudflare’s extensive network and global insight into the origins of DNS, email or web traffic, combined with Cloudflare Area 1’s datasets of campaign tactics, techniques, and procedures (TTPs), seed infrastructure and threat models — we are now better positioned than ever to help organizations secure themselves against sophisticated threat actor activity, and regain the advantage that for so long has been heavily weighted towards the bad guys.

If you’d like to extend Zero Trust to your email security to block advanced threats, contact your Customer Success manager, or request a Phishing Risk Assessment here.

How to replace your email gateway with Cloudflare Area 1

Post Syndicated from Shalabh Mohan original https://blog.cloudflare.com/replace-your-email-gateway-with-area-1/

How to replace your email gateway with Cloudflare Area 1

How to replace your email gateway with Cloudflare Area 1

Leaders and practitioners responsible for email security are faced with a few truths every day. It’s likely true that their email is cloud-delivered and comes with some built-in protection that does an OK job of stopping spam and commodity malware. It’s likely true that they have spent considerable time, money, and staffing on their Secure Email Gateway (SEG) to stop phishing, malware, and other email-borne threats. Despite this, it’s also true that email continues to be the most frequent source of Internet threats, with Deloitte research finding that 91% of all cyber attacks begin with phishing.

If anti-phishing and SEG services have both been around for so long, why do so many phish still get through? If you’re sympathetic to Occam’s razor, it’s because the SEG was not designed to protect the email environments of today, nor is it effective at reliably stopping today’s phishing attacks.

But if you need a stronger case than Occam delivers — then keep on reading.

Why the world has moved past the SEG

The most prominent change within the email market is also what makes a traditional SEG redundant – the move to cloud-native email services. More than 85% of organizations are expected to embrace a “cloud-first” strategy by 2025, according to Gartner®. Organizations that expect cloud-native scale, resiliency, and flexibility from their security controls are not going to get it from legacy devices such as SEGs.

When it comes to email specifically, Gartner® notes that, “Advanced email security capabilities are increasingly being deployed as integrated cloud email security solutions rather than as a gateway” – with at least 40% of organizations using built-in protection capabilities from cloud email providers instead of a SEG, by 2023. Today, email comes from everywhere and goes everywhere – putting a SEG in front of your Exchange server is anachronistic; and putting a SEG in front of cloud inboxes in a mobile and remote-first world is intractable. Email security today should follow your user, should be close to your inbox, and should “be everywhere”.

Apart from being architecturally out of time, a SEG also falls short at detecting advanced phishing and socially engineered attacks. This is because a SEG was originally designed to stop spam – a high-volume problem that needs large attack samples to detect and nullify. But today’s phishing attacks are more sniper than scattergun. They are low volume, highly targeted, and exploit our implicit trust in email communications to steal money and data. Detecting modern phishing attacks requires compute-intensive advanced email analysis and threat detection algorithms that a SEG cannot perform at scale.

Nowhere is a SEG’s outdated detection philosophy more laid bare than when admins are confronted with a mountain of email threat policies to create and tune. Unlike most other cyber attacks, email phishing and Business Email Compromise (BEC) have too many “fuzzy” signals and cannot solely be detected by deterministic if-then statements. Moreover, attackers don’t stand still while you create email threat policies – they adapt fast and modify techniques to bypass the rules you just created. Relying on SEG tuning to stop phishing is like playing a game of Whack-A-Mole rigged in the attacker’s favor.

How to replace your email gateway with Cloudflare Area 1

To stop phishing, look ahead

Traditional email security defenses rely on knowledge of yesterday’s active attack characteristics, such as reputation data and threat signatures, to detect the next attack, and therefore can’t reliably defend against modern phishing attacks that continually evolve.

What’s needed is forward-looking security technology that is aware not only of yesterday’s active phishing payloads, websites, and techniques — but also has insight into the threat actors’ next moves. Which sites and accounts are they compromising or establishing for use in tomorrow’s attacks? What payloads and techniques are they preparing to use in those attacks? Where are they prodding and probing before an attack?

Cloudflare Area 1 proactively scans the Internet for attacker infrastructure and phishing campaigns that are under construction. Area 1’s threat-focused web crawlers dynamically analyze suspicious web pages and payloads, and continuously update detection models as attacker tactics evolve – all to stop phishing attacks days before they reach the inbox.

When combined with the 1T+ daily DNS requests observed by Cloudflare Gateway, this corpus of threat intelligence enables customers to stop phishing threats at the earliest stage of the attack cycle. In addition, the use of deep contextual analytics to understand message sentiment, tone, tenor and thread variations allows Area 1 to understand and distinguish between valid business process messages and sophisticated impersonation campaigns.

While we are big believers in layering security, the layers should not be redundant. A SEG duplicates a lot of capabilities that customers now get bundled in with their cloud email offering. Area 1 is built to enhance – not duplicate – native email security and stop phishing attacks that get past initial layers of defense.

How to replace your email gateway with Cloudflare Area 1

Planning for your SEG replacement project

The best way to get started with your SEG replacement project is deciding whether it’s a straight replacement or an eventual replacement that starts with augmentation. While Cloudflare Area 1 has plenty of customers that have replaced their SEG (more on that later), we have also seen scenarios where customers prefer to run Cloudflare Area 1 downstream of their SEG initially, assess the efficacy of both services, and then make a more final determination. We make the process straightforward either way!

As you start the project, it’s important to involve the right stakeholders. At a minimum, you should involve an IT admin to ensure email delivery and productivity isn’t impacted and a security admin to monitor detection efficacy. Other stakeholders might include your channel partner if that’s your preferred procurement process and someone from the privacy and compliance team to verify proper handling of data.

Next, you should decide your preferred Cloudflare Area 1 deployment architecture. Cloudflare Area 1 can be deployed as the MX record, over APIs, and can even run in multi-mode deployment. We recommend deploying Cloudflare Area 1 as the MX record for the most effective protection against external threats, but the service fits into your world based on your business logic and specific needs.

The final piece of preparation involves mapping out your email flow. If you have multiple domains, identify where emails from each of your domains route to. Check your different routing layers (e.g. are there MTAs that relay inbound messages?). Having a good understanding of the logical and physical SMTP layers within the organization will ensure proper routing of messages. Discuss what email traffic Cloudflare Area 1 should scan (north/south, east/west, both) and where it fits with your existing email policies.

Executing the transition plan

Step 1: Implement email protection
Here are the broad steps you should follow if Cloudflare Area 1 is configured as the MX record (time estimate: ~30 minutes):

  • Configure the downstream service to accept mail from Cloudflare Area 1.
  • Ensure that Cloudflare Area 1’s egress IPs are not rate limited or blocked as this would affect delivery of messages.
  • If the email server is on-premises, update firewall rules to allow Cloudflare Area 1 to deliver to these systems.
  • Configure remediation rules (e.g. quarantine, add subject or message body prefix, etc.).
  • Test the message flow by injecting messages into Cloudflare Area 1 to confirm proper delivery. (our team can assist with this step.)
  • Update MX records to point to Cloudflare Area 1.

Here are the steps if Cloudflare Area 1 is deployed downstream from an existing email security solution (time estimate: ~30 minutes):

  • Configure the proper look back hops on Cloudflare Area 1, so that Cloudflare Area 1 can detect the original sender IP address.
  • If your email server is on-premises, update firewall rules to allow Cloudflare Area 1 to deliver to the email server.
  • Configure remediation rules (e.g. quarantine, add subject or message body prefix, etc.).
  • Test the message flow by injecting messages into Cloudflare Area 1 to confirm proper delivery. (our team can assist with this step.)
  • Update the delivery routes on your SEG to deliver all mail to Cloudflare Area 1, instead of the email servers.

Step 2: Integrate DNS
One of the most common post-email steps customers follow is to integrate Cloudflare Area 1 with their DNS service. If you’re a Cloudflare Gateway customer, good news – Cloudflare Area 1 now uses Cloudflare Gateway as its recursive DNS to protect end users from accessing phishing and malicious sites through email links or web browsing.

Step 3: Integrate with downstream security monitoring and remediation services
Cloudflare Area 1’s detailed and customizable reporting allows for at-a-glance visibility into threats. By integrating with SIEMs through our robust APIs, you can easily correlate Cloudflare Area 1 detections with events from network, endpoint and other security tools for simplified incident management.

While Cloudflare Area 1 provides built-in remediation and message retraction to allow customers to respond to threats directly within the Cloudflare Area 1 dashboard, many organizations also choose to integrate with orchestration tools for custom response playbooks. Many customers leverage our API hooks to integrate with SOAR services to manage response processes across their organization.

How to replace your email gateway with Cloudflare Area 1

Metrics to measure success

How will you know your SEG replacement project has been successful and had the desired impact? We recommend measuring metrics relevant to both detection efficacy and operational simplicity.

On the detection front, the obvious metric to measure is the number and nature of phishing attacks blocked before and after the project. Are you seeing new types of phishing attacks being blocked that you weren’t seeing before? Are you getting visibility into campaigns that hit multiple mailboxes? The other detection-based metric to keep in mind is the number of false positives.

On the operational front, it’s critical that email productivity isn’t impacted. A good proxy for this is measuring the number of IT tickets related to email delivery. The availability and uptime of the email security service is another key lever to keep an eye on.

Finally, and perhaps most importantly, measure how much time your security team is spending on email security. Hopefully it’s much less than before! A SEG is known to be a heavy-lift service deployment to ongoing maintenance. If Cloudflare Area 1 can free up your team’s time to work on other pressing security concerns, that’s as meaningful as stopping the phish themselves.

You have lots of company

The reason we are articulating a SEG replacement plan here is because many of our customers have done it already and are happy with the outcomes.

For example, a Fortune 50 global insurance provider that serves 90 million customers in over 60 countries found their SEG to be insufficient in stopping phishing attacks. Specifically, it was an onerous process to search for “missed phish” once they got past the SEG and reached the inbox. They needed an email security service that could catch these phishing attacks and support a hybrid architecture with both cloud and on-premises mailboxes.

After deploying Cloudflare Area 1 downstream of their Microsoft 365 and SEG layers, our customer was protected against more than 14,000 phishing threats within the first month; none of those phishing messages reached a user’s inbox. A one-step integration with existing email infrastructure meant that maintenance and operational issues were next to none. Cloudflare Area 1’s automated message retraction and post-delivery protection also enabled the insurance provider to easily search and remediate any missed phish as well.

If you are interested in speaking with any of our customers that have augmented or replaced their SEG with Cloudflare Area 1, please reach out to your account team to learn more! If you’d like to see Cloudflare Area 1 in action, sign up for a Phishing Risk Assessment here.

Replacing a SEG is a great project to fit into your overall Zero Trust roadmap. For a full summary of Cloudflare One Week and what’s new, tune in to our recap webinar.

1Gartner Press Release, “Gartner Says Cloud Will Be the Centerpiece of New Digital Experiences”, 11 November 2021
2Gartner, “Market Guide for Email Security,” 7 October 2021, Mark Harris, Peter Firstbrook, Ravisha Chugh, Mario de Boer
GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.

Introducing browser isolation for email links to stop modern phishing threats

Post Syndicated from Shalabh Mohan original https://blog.cloudflare.com/email-link-isolation/

Introducing browser isolation for email links to stop modern phishing threats

This post is also available in 简体中文, 日本語 and Español.

Introducing browser isolation for email links to stop modern phishing threats

There is an implicit and unearned trust we place in our email communications. This realization — that an organization can’t truly have a Zero Trust security posture without including email — was the driving force behind Cloudflare’s acquisition of Area 1 Security earlier this year.  Today, we have taken our first step in this exciting journey of integrating Cloudflare Area 1 email security into our broader Cloudflare One platform. Cloudflare Secure Web Gateway customers can soon enable Remote Browser Isolation (RBI) for email links, giving them an unmatched level of protection from modern multi-channel email-based attacks.

Research from Cloudflare Area 1 found that nearly 10% of all observed malicious attacks involved credential harvesters, highlighting that victim identity is what threat actors usually seek. While commodity phishing attacks are blocked by existing security controls, modern attacks and payloads don’t have a set pattern that can reliably be matched with a block or quarantine rule. Additionally, with the growth of multi-channel phishing attacks, an effective email security solution needs the ability to detect blended campaigns spanning email and Web delivery, as well as deferred campaigns that are benign at delivery time, but weaponized at click time.

When enough “fuzzy” signals exist, isolating the destination to ensure end users are secure is the most effective solution. Now, with the integration of Cloudflare Browser Isolation into Cloudflare Area 1 email security, these attacks can now be easily detected and neutralized.

Human error is human

Why do humans still click on malicious links? It’s not because they haven’t attended enough training sessions or are not conscious about security. It’s because they have 50 unread emails in their inbox, have another Zoom meeting to get to, or are balancing a four-year old on their shoulders. They are trying their best. Anyone, including security researchers, can fall for socially engineered attacks if the adversary is well-prepared.

If we accept that human error is here to stay, developing security workflows introduces new questions and goals:

  • How can we reduce, rather than eliminate, the likelihood of human error?
  • How can we reduce the impact of human error when, not if, it happens?
  • How can security be embedded into an employee’s existing daily workflows?

It’s these questions that we had in mind when we reached the conclusion that email needs to be a fundamental part of any Zero Trust platform. Humans make mistakes in email just as regularly — in fact, sometimes more so — as they make mistakes surfing the Web.

To block, or not to block?

For IT teams, that is the question they wrestle with daily to balance risk mitigation with user productivity. The SOC team wants IT to block everything risky or unknown, whereas the business unit wants IT to allow everything not explicitly bad. If IT decides to block risky or unknown links, and it results in a false positive, they waste time manually adding URLs to allow lists — and perhaps the attacker later pivots those URLs to malicious content anyway. If IT decides to allow risky or unknown sites, best case they waste time reimaging infected devices and resetting login credentials — but all too common, they triage the damage from a data breach or ransomware lockdown. The operational simplicity of enabling RBI with email — also known as email link isolation — saves the IT, SOC, and business unit teams significant time.

How it works

For a Cloudflare Area 1 customer, the initial steps involve enabling RBI within your portal:

Introducing browser isolation for email links to stop modern phishing threats

With email link isolation in place, here’s the short-lived life of an email with suspicious links:

Step 1: Cloudflare Area 1 inspects the email and determines that certain links in the messages are suspicious or on the margin

Step 2: Suspicious URLs and hyperlinks in the email get rewritten to a custom Cloudflare Area 1 prefix URL.

Step 3: The email is delivered to the intended inboxes.

Step 4: If a user clicks the link in the email, Cloudflare redirects to a remote browser via <authdomain>.cloudflareaccess.com/browser/{{url}}.

Step 5: Remote browser loads a website on a server on the Cloudflare Global Network and serves draw commands to the user’s clientless browser endpoint.

By executing the browser code and controlling user interactions on a remote server rather than a user device, any and all malware and phishing attempts are isolated, and won’t infect devices and compromise user identities. This improves both user and endpoint security when there are unknown risks and unmanaged devices, and allows users to access websites without having to connect to a VPN or having strict firewall policies.

Cloudflare’s RBI technology uses a unique patented technology called Network Vector Rendering (NVR) that utilizes headless Chromium-based browsers in the cloud, transparently intercepts draw layer output, transmits the draw commands efficiency and securely over the web, and redraws them in the windows of local HTML5 browsers. Unlike legacy Browser Isolation technologies that relied on pixel pushing or DOM reconstruction, NVR is optimized for scalability, security and end user transparency, while ensuring the broadest compatibility with websites.

Introducing browser isolation for email links to stop modern phishing threats

Let’s look at a specific example of a deferred phishing attack, how it slips past traditional defenses, and how email link isolation addresses the threat.

As organizations look to adopt new security principles and network architectures like Zero Trust, adversaries continually come up with techniques to bypass these controls by exploiting the most used and most vulnerable application – email. Email is a good candidate for compromise because of its ubiquity and ability to be bypassed pretty easily by a motivated attacker.

Let’s take an example of a “deferred phishing attack”, without email link isolation.

Introducing browser isolation for email links to stop modern phishing threats

Attacker preparation: weeks before launch
The attacker sets up infrastructure for the phishing attempt to come. This may include:

  • Registering a domain
  • Encrypting it with SSL
  • Setting up proper email authentication (SPF, DKIM, DMARC)
  • Creating a benign web page

At this point, there is no evidence of an attack that can be picked up by secure email gateways, authentication-based solutions, or threat intelligence that relies solely on reputation-based signals and other deterministic detection techniques.

Attack “launch”: Sunday afternoon
The attacker sends an authentic-looking email from the newly-created domain. This email includes a link to the (still benign) webpage. There’s nothing in the email to block or flag it as suspicious. The email gets delivered to intended inboxes.

Attack launch: Sunday evening
Once the attacker is sure that all emails have reached their destination, they pivot the link to a malicious destination by changing the attacker-controlled webpage, perhaps by creating a fake login page to harvest credentials.

Attack landing: Monday morning
As employees scan their inboxes to begin their week, they see the email. Maybe not all of them click the link, but some of them do. Maybe not all of those that clicked enter their credentials, but a handful do. Without email link isolation, the attack is successful.

The consequences of the attack have also just begun – once user login credentials are obtained, attackers can compromise legitimate accounts, distribute malware to your organization’s network, steal confidential information, and cause much more downstream damage.

The integration between Cloudflare Area 1 and Cloudflare Browser Isolation provides a critical layer of post-delivery protection that can foil attacks like the deferred phishing example described above.

If the attacker prepares for and executes the attack as stated in the previous section, our email link isolation would analyze the email link at the time of click and perform a high-level assessment on whether the user should be able to navigate to it.

Safe link – Users will be redirected to this site transparently

Malicious link Users are blocked from navigating

Suspicious link Users are heavily discouraged to navigating and are presented with a splash warning page encouraging them to view in the link in an isolated browser

Introducing browser isolation for email links to stop modern phishing threats
Introducing browser isolation for email links to stop modern phishing threats

While a splash warning page was the mitigation employed in the above example, email link isolation will also offer security administrators other customizable mitigation options as well, including putting the webpage in read-only mode, restricting the download and upload of files, and disabling keyboard input altogether within their Cloudflare Gateway consoles.

Email link isolation also fits into users’ existing workflows without impacting productivity or sapping their time with IT tickets. Because Cloudflare Browser Isolation is built and deployed on the Cloudflare network, with global locations in 270 cities, web browsing sessions are served as close to users as possible, minimizing latency. Additionally, Cloudflare Browser Isolation sends the final output of each webpage to a user instead of page scrubbing or sending a pixel stream, further reducing latency and not breaking browser-based applications such as SaaS.

How do I get started?

Existing Cloudflare Area 1 and Cloudflare Gateway customers are eligible for the beta release of email link isolation. To learn more and to express interest, sign up for our upcoming beta.

If you’d like to see what threats Cloudflare Area 1 detects on your live email traffic, request a free phishing risk assessment here. It takes five minutes to get started and does not impact mail flow.

Why we are acquiring Area 1

Post Syndicated from John Graham-Cumming original https://blog.cloudflare.com/why-we-are-acquiring-area-1/

Why we are acquiring Area 1

This post is also available in Français and Español.

Why we are acquiring Area 1

Cloudflare’s mission is to help build a better Internet. We’ve invested heavily in building the world’s most powerful cloud network to deliver a faster, safer and more reliable Internet for our users. Today, we’re taking a big step towards enhancing our ability to secure our customers.

Earlier today we announced that Cloudflare has agreed to acquire Area 1 Security. Area 1’s team has built exceptional cloud-native technology to protect businesses from email-based security threats. Cloudflare will integrate Area 1’s technology with our global network to give customers the most complete Zero Trust security platform available.

Why Email Security?

Back at the turn of the century I was involved in the fight against email spam. At the time, before the mass use of cloud-based email, spam was a real scourge. Clogging users’ inboxes, taking excruciatingly long to download, and running up people’s Internet bills. The fight against spam involved two things, one technical and one architectural.

Technically, we figured out how to use machine-learning to successfully differentiate between spam and genuine. And fairly quickly email migrated to being largely cloud-based. But together these changes didn’t kill spam, but they relegated to a box filled with junk that rarely needs to get looked at.

What spam didn’t do, although for a while it looked like it might, was kill email. In fact, email remains incredibly important. And because of its importance it’s a massive vector for threats against businesses and individuals.

And whilst individuals largely moved to cloud-based email many companies still have on-premise email servers. And, much like anything else in the cybersecurity world, email needs best-in-class protection, not just what’s built in with the email provider being used.

When Cloudflare was in its infancy we considered dealing with the email-borne threat problem but opted to concentrate on building defences for networks and the web. Over time, we’ve vastly expanded our protection and our customers are using us to protect the entirety of their Internet-facing world.

Whilst we can protect a mail server from DDoS, for example, using Magic Transit, that’s just one potential way in which email gets attacked. And far more insidious are emails sent into organizations containing scams, malware and other threats. Just as Cloudflare protects applications that use HTTP, we need to protect email at the application and content level.

If you read the press, few weeks go by without reading a news story about how an organization had significant data compromised because an employee fell for a phishing email.

Cyberthreats are entering businesses via email. Area 1 estimates that more than 90% of cyber security damages are the result of just one thing: phishing. Let’s be clear, email is the biggest exposure for any business.

Existing email security solutions aren’t quite cutting it. Historically, companies have addressed email threats by layering legacy box-based products. And layering they are, as around 1 in 7 Fortune 1000 companies use two or more email security solutions1. If you know Cloudflare, you know legacy boxes are not our thing. As businesses continue to move to the cloud, so does email. Gartner estimates 71% of companies use cloud or hybrid cloud email, with Google’s G Suite and Microsoft’s Office 365 being the most common solutions2. While these companies offer built-in protection capabilities for their email products, many companies do not believe they adequately protect users (more on our own experience with these shortfalls later).

Why we are acquiring Area 1

Trying before buying  

Email security is something that has been on our mind for some time.

Last year we rolled out Email Security DNS Wizard, our first email security product. It was designed as a tool to tackle email spoofing and phishing and improve the deliverability of millions of emails. This was just the first step on our email security journey. Bringing Area 1 onboard is the next, and much larger, step in that journey.

As a security company, we are constantly being attacked. We have been using Area 1 for some time to protect our employees from these attackers.

In early 2020, our security team saw an uptick in employee-reported phishing attempts. Our cloud-based email provider had strong spam filtering, but fell short at blocking malicious threats and other advanced attacks. Additionally, our provider only offered controls to cover their native web application, and did not provide sufficient controls to protect their iOS app and alternate methods of accessing email. Clearly, we needed to layer an email security solution on top of their built-in protection capabilities (more on layering later…).

The team looked for four main things in a vendor: the ability to scan email attachments, the ability to analyze suspected malicious links, business email compromise protection, and strong APIs into cloud-native email providers. After testing many vendors, Area 1 became the clear choice to protect our employees. We implemented Area 1’s solution in early 2020, and the results have been fantastic. With Area 1, we’ve been able to proactively identify phishing campaigns and take action against them before they cause damage. We saw a significant and prolonged drop in phishing emails. Not only that, the Area 1 service had little to no impact on email productivity, which means there were minimal false positives distracting our security team.

In fact, Area 1’s technology was so effective at launch, that our CEO reached out to our Chief Security Officer to inquire if our email security was broken. Our CEO hadn’t seen any phishing attempts reported by our employees for many weeks, a rare occurrence. It turns out our employees weren’t reporting any phishing attempts, because Area 1 was catching all phishing attempts before they reached our employee’s inboxes.

The reason Area 1 is able to do a better job than other providers out there is twofold. First, they have built a significant data platform that is able to identify patterns in emails. Where does an email come from? What does it look like? What IP does it come from? Area 1 has been in the email security space for nine years, and they have amassed an incredibly valuable trove of threat intelligence data. In addition, they have used this data to train state-of-the-art machine learning models to act preemptively against threats.

Layers (Email Security + Zero Trust)

Offering a cloud-based email security product makes sense on its own, but our vision for joining Area 1’s technology to Cloudflare is much larger. We are convinced that adding email security to our existing Zero Trust security platform will result in the best protection for our customers.

Why we are acquiring Area 1

Just as Cloudflare had put Area 1 in front of our existing email solution, many companies put two or more layered email protection products together. But layering is hard. Different products have different configuration mechanisms (some might use a UI, others an API, others might not support Terraform etc.), different reporting mechanisms, and incompatibilities that have to be worked around.

SMTP, the underlying email protocol, has been around since 1982 and in the intervening 40 years a lot of protocols have grown around SMTP to make it secure, add spoof protection, verify senders, and more. Getting layered email security products to work well with all those add-on protocols is hard.

And email doesn’t stand alone. The user’s email address is often the same thing as their company log in. It makes sense to bring Zero Trust and email security together.

Why we are acquiring Area 1

As we’ve discussed, email is a major vector for attacks, but it is not the only one. Email security is just one layer of an enterprise defense system. Most businesses have multiple layers of security to protect their employees and their assets. These defense layers reduce the risk that a system gets penetrated by an attacker. Now imagine all these layers were purpose-built to work with each other seamlessly, built into the same software stack, offered by a single vendor and available to you in 250+ locations around the world.

Imagine a world where you can turn on email security to protect you against phishing, but if for some reason an attacker were to get through to an employee’s inbox, you can create a rule to open any unrecognized link in an isolated remote browser with no text input allowed and scan all email attachments for known malware. That is the power of what we hope to achieve by adding Area 1’s technology onto Cloudflare’s Zero Trust security platform.

Bringing email and Zero Trust together opens up a world of possibilities in protecting email and the enterprise.

Shared Intelligence

At Cloudflare, we’re fans of closely knit products that deliver more value together than they do apart. We refer to that internally as 1+1=3. Incorporating Area 1 into our Zero Trust platform will deliver significant value to our customers, but protecting email is just the start.

Area 1 has spent years training their machine learning models with email data to deliver world-class security. Joining email threat data and Cloudflare’s threat data from our global network will give us incredible power to deliver improved security capabilities for our customers across our products.

Why we are acquiring Area 1

Shared vision

Together with the Area 1 team, we will continue to help build the world’s most robust cloud network and Zero Trust security platform.

On a final note, what struck us most about Area 1 is their shared vision for building a better (and more secure) Internet. Their team is smart, transparent, and curious, all traits we value tremendously at Cloudflare. We are convinced that together our teams can deliver tremendous value to our customers.

If you are interested in upcoming email security products, please register your interest here. You can learn more about the acquisition here or in Area 1’s blog.

The acquisition is expected to close early in the second quarter of 2022 and is subject to customary closing conditions. Until the transaction closes, Cloudflare and Area 1 Security remain separate and independent companies.

Why we are acquiring Area 1


1Piper Sandler 1Q2021 Email Security Survey: Market Share
2Gartner, Market Guide for Email Security, 8 September 2020

Complying with DMARC across multiple accounts using Amazon SES

Post Syndicated from Brendan Paul original https://aws.amazon.com/blogs/messaging-and-targeting/complying-with-dmarc-across-multiple-accounts-using-amazon-ses/


For enterprises of all sizes, email is a critical piece of infrastructure that supports large volumes of communication from an organization. As such, companies need a robust solution to deal with the complexities this may introduce. In some cases, companies have multiple domains that support several different business units and need a distributed way of managing email sending for those domains. For example, you might want different business units to have the ability to send emails from subdomains, or give a marketing company the ability to send emails on your behalf. Amazon Simple Email Service (Amazon SES) is a cost-effective, flexible, and scalable email service that enables developers to send mail from any application. One of the benefits of Amazon SES is that you can configure Amazon SES to authorize other users to send emails from addresses or domains that you own (your identities) using their own AWS accounts. When allowing other accounts to send emails from your domain, it is important to ensure this is done securely. Amazon SES allows you to send emails to your users using popular authentication methods such as DMARC. In this blog, we walk you through 1/ how to comply with DMARC when using Amazon SES and 2/ how to enable other AWS accounts to send authenticated emails from your domain.

DMARC: what is it, why is it important?

DMARC stands for “Domain-based Message Authentication, Reporting & Conformance”, and it is an email authentication protocol (DMARC.org). DMARC gives domain owners and email senders a way to protect their domain from being used by malicious actors in phishing or spoofing attacks. Email spoofing can be used as a way to compromise users’ financial or personal information by taking advantage of their trust of well-known brands. DMARC makes it easier for senders and recipients to determine whether or not an email was actually sent by the domain that it claims to have been sent by.

Solution Overview

In this solution, you will learn how to set up DKIM signing on Amazon SES, implement a DMARC Policy, and enable other accounts in your organization to send emails from your domain using Sending Authorization. When you set up DKIM signing, Amazon SES will attach a digital signature to all outgoing messages, allowing recipients to verify that the email came from your domain. You will then set your DMARC Policy, which tells an email receiver what to do if an email is not authenticated. Lastly, you will set up Sending Authorization so that other AWS accounts can send authenticated emails from your domain.


In order to complete the example illustrated in this blog post, you will need to have:

  1. A domain in an Amazon Route53 Hosted Zone or third-party provider. Note: You will need to add/update records for the domain. For this blog we will be using Route53.
  2. An AWS Organization
  3. A second AWS account to send Amazon SES Emails within a different AWS Organizations OU. If you have not worked with AWS Organizations before, review the Organizations Getting Started Guide

How to comply with DMARC (DKIM and SPF) in Amazon SES

In order to comply with DMARC, you must authenticate your messages with either DKIM (DomainKeys Identified Mail), SPF (Sender Policy Framework), or both. DKIM allows you to send email messages with a cryptographic key, which enables email providers to determine whether or not the email is authentic. SPF defines what servers are allowed to send emails for their domain. To use SPF for DMARC compliance you need to set up a custom MAIL FROM domain in Amazon SES. To authenticate your emails with DKIM in Amazon SES, you have the option of:

In this blog, you will be setting up a sending identity.

Setting up DKIM Signing in Amazon SES

  1. Navigate to the Amazon SES Console 
  2. Select Verify a New Domain and type the name of your domain in
  3. Select Generate DKIM Settings
  4. Choose Verify This Domain
    1. This will generate the DNS records needed to complete domain verification, DKIM signing, and routing incoming mail.
    2. Note: When you initiate domain verification using the Amazon SES console or API, Amazon SES gives you the name and value to use for the TXT record. Add a TXT record to your domain’s DNS server using the specified Name and Value. Amazon SES domain verification is complete when Amazon SES detects the existence of the TXT record in your domain’s DNS settings.
  5. If you are using Route 53 as your DNS provider, choose the Use Route 53 button to update the DNS records automatically
    1. If you are not using Route 53, go to your third-party provider and add the TXT record to verify the domain as well as the three CNAME records to enable DKIM signing. You can also add the MX record at the end to route incoming mail to Amazon SES.
    2. A list of common DNS Providers and instructions on how to update the DNS records can be found in the Amazon SES documentation
  6. Choose Create Record Sets if you are using Route53 as shown below or choose Close after you have added the necessary records to your third-party DNS provider.


Note: in the case that you previously verified a domain, but did NOT generate the DKIM settings for your domain, follow the steps below. Skip these steps if this is not the case:

  1. Go to the Amazon SES Console, and select your domain
  2. Select the DKIM dropdown
  3. Choose Generate DKIM Settings and copy the three values in the record set shown
    1. You may also download the record set as a CSV file
  4. Navigate to the Route53 console or your third-party DNS provider. Instructions on how to update the DNS records in your third-party can be found in the Amazon SES documentation
  5. Select the domain you are using
  6. Choose Create Record

  1. Enter the values that Amazon SES has generated for you, and add the three CNAME records to your domain
  2. Wait a few minutes, and go back to your domain in the Amazon SES Console
  3. Check that the DKIM status is verified

You also want to set up a custom MAIL FROM domain that you will use later on. To do so, follow the steps in the documentation.

Setting up a DMARC policy on your domain

DMARC policies are TXT records you place in DNS to define what happens to incoming emails that don’t align with the validations provided when setting up DKIM and SPF. With this policy, you can choose to allow the email to pass through, quarantine the email into a folder like junk or spam, or reject the email.

As a best practice, you should start with a DMARC policy that doesn’t reject all email traffic and collect reports on emails that don’t align to determine if they should be allowed. You can also set a percentage on the DMARC policy to perform filtering on a subset of emails to, for example, quarantine only 50% of the emails that don’t align. Once you are in a state where you can begin to reject non-compliant emails, flip the policy to reject failed authentications. When you set the DMARC policy for your domain, any subdomains that are authorized to send on behalf of your domain will inherit this policy and the same rule will apply. For more information on setting up a DMARC policy, see our documentation.

In a scenario where you have multiple subdomains sending emails, you should be setting the DMARC policy for the organizational domain that you own. For example, if you own the domain example.com and also want to use the sub-domain sender.example.com to send emails you can set the organizational DMARC policy (as a DNS TXT record) to:

Name Type Value
1 _dmarc.example.com TXT “v=DMARC1;p=quarantine;pct=50;rua=mailto:[email protected]

This DMARC policy states that 50% of emails coming from example.com that fail authentication should be quarantined and you want to send a report of those failures to [email protected]. For your sender.example.com sub-domain, this policy will be inherited unless you specify another DMARC policy for our sub-domain. In the case where you want to be stricter on the sub-domain you could add another DMARC policy like you see in the following table.


Name Type Value
1 _dmarc.sender.example.com TXT “v=DMARC1;p=reject;pct=100;rua=mailto:[email protected];ruf=mailto:[email protected]

This policy would apply to emails coming from sender.example.com and would reject any email that fails authentication. It would also send aggregate feedback to [email protected] and detailed message-specific failure information to [email protected] for further analysis.

Sending Authorization in Amazon SES – Allowing Other Accounts to Send Authenticated Emails

Now that you have configured Amazon SES to comply with DMARC in the account that owns your identity, you may want to allow other accounts in your organization the ability to send emails in the same way. Using Sending Authorization, you can authorize other users or accounts to send emails from identities that you own and manage. An example of where this could be useful is if you are an organization which has different business units in that organization. Using sending authorization, a business unit’s application could send emails to their customers from the top-level domain. This application would be able to leverage the authentication settings of the identity owner without additional configuration. Another advantage is that if the business unit has its own subdomain, the top-level domain’s DKIM settings can apply to this subdomain, so long as you are using Easy DKIM in Amazon SES and have not set up Easy DKIM for the specific subdomains.

Setting up sending authorization across accounts

Before you set up sending authorization, note that working across multiple accounts can impact bounces, complaints, pricing, and quotas in Amazon SES. Amazon SES documentation provides a good understanding of the impacts when using multiple accounts. Specifically, delegated senders are responsible for bounces and complaints and can set up notifications to monitor such activities. These also count against the delegated senders account quotas. To set up Sending Authorization across accounts:

  1. Navigate to the Amazon SES Console from the account that owns the Domain
  2. Select Domains under Identity Management
  3. Select the domain that you want to set up sending authorization with
  4. Select View Details
  5. Expand Identity Policies and Click Create Policy
  6. You can either create a policy using the policy generator or create a custom policy. For the purposes of this blog, you will create a custom policy.
  7. For the custom policy, you will allow a particular Organization Unit (OU) from our AWS Organization access to our domain. You can also limit access to particular accounts or other IAM principals. Use the following policy to allow a particular OU to access the domain:

  “Version”: “2012-10-17”,
  “Id”: “AuthPolicy”,
  “Statement”: [
      “Sid”: “AuthorizeOU”,
      “Effect”: “Allow”,
      “Principal”: “*”,
      “Action”: [
      “Resource”: “<Arn of Verified Domain>”,
      “Condition”: {
        “ForAnyValue:StringLike”: {
          “aws:PrincipalOrgPaths”: “<Organization Id>/<Root OU Id>/<Organizational Unit Id>”

9. Make sure to replace the escaped values with your Verified Domain ARN and the Org path of the OU you want to limit access to.


You can find more policy examples in the documentation. Note that you can configure sending authorization such that all accounts under your AWS Organization are authorized to send via a certain subdomain.


You can now test the ability to send emails from your domain in a different AWS account. You will do this by creating a Lambda function to send a test email. Before you create the Lambda function, you will need to create an IAM role for the Lambda function to use.

Creating the IAM Role:

  1. Log in to your separate AWS account
  2. Navigate to the IAM Management Console
  3. Select Role and choose Create Role
  4. Under Choose a use case select Lambda
  5. choose Next: Permissions
  6. In the search bar, type SES and select the check box next to AmazonSESFullAccess
  7. Choose Next:Tags and Review
  8. Give the role a name of your choosing, and choose Create Role

Navigate to Lambda Console

  1. Select Create Function
  2. Choose the box marked Author from Scratch
  3. Give the function a name of your choosing (Ex: TestSESfunction)
  4. In this demo, you will be using Python 3.8 runtime, but feel free to modify to your language of choice
  5. Select the Change default execution role dropdown, and choose the Use an existing role radio button
  6. Under Existing Role, choose the role that you created in the previous step, and create the function

Edit the function

  1. Navigate to the Function Code portion of the page and open the function python file
  2. Replace the default code with the code shown below, ensuring that you put your own values in based on your resources
  3. Values needed:
    1. Test Email Address: an email address you have access to
      1. NOTE: If you are still operating in the Amazon SES Sandbox, this will need to be a verified email in Amazon SES. To verify an email in Amazon SES, follow the process here. Alternatively, here is how you can move out of the Amazon SES Sandbox
    2. SourceArn: The arn of your domain. This can be found in Amazon SES Console → Domains → <YourDomain> → Identity ARN
    3. ReturnPathArn: The same as your Source ARN
    4. Source: This should be your Mail FROM Domain @ your domain
      1. Your Mail FROM Domain can be found under Domains → <YourDomain> → Mail FROM Domain dropdown
      2. Ex: [email protected]
    5. Use the following function code for this example

import json
import boto3
from botocore.exceptions import ClientError

client = boto3.client('ses')
def lambda_handler(event, context):
    # Try to send the email.
        #Provide the contents of the email.
        response = client.send_email(
                'ToAddresses': [
                    '<[email protected]>',
                'Body': {
                    'Html': {
                        'Charset': 'UTF-8',
                        'Data': 'This email was sent with Amazon SES.',
                'Subject': {
                    'Charset': 'UTF-8',
                    'Data': 'Amazon SES Test',
            Source='<[email protected]>',
    # Display an error if something goes wrong.
    except ClientError as e:
        print("Email sent! Message ID:"),

  1. Once you have replaced the appropriate values, choose the Deploy button to deploy your changes

Run a Test invocation

  1. After you have deployed your changes, select the “Test” Panel above your function code

  1. You can leave all of these keys and values as default, as the function does not use any event parameters
  2. Choose the Invoke button in the top right corner
  3. You should see this above the test event window:

Verifying that the Email has been signed properly

Depending on your email provider, you may be able to check the DKIM signature directly in the application. As an example, for Outlook, right click on the message, and choose View Source from the menu. You should see line that shows the Authentication Results and whether or not the DKIM/SPF signature passed. For Gmail, go to your Gmail Inbox on the Gmail web app. Choose the message you wish to inspect, and choose the More Icon. Choose View Original from the drop-down menu. You should then see the SPF and DKIM “PASS” Results.


To clean up the resources in your account,

  1. Navigate to the Route53 Console
  2. Select the Hosted Zone you have been working with
  3. Select the CNAME, TXT, and MX records that you created earlier in this blog and delete them
  4. Navigate to the SES Console
  5. Select Domains
  6. Select the Domain that you have been working with
  7. Click the drop down Identity Policies and delete the one that you created in this blog
  8. If you verified a domain for the sake of this blog: navigate to the Domains tab, select the domain and select Remove
  9. Navigate to the Lambda Console
  10. Select Functions
  11. Select the function that you created in this exercise
  12. Select Actions and delete the function


In this blog post, we demonstrated how to delegate sending and management of your sub-domains to other AWS accounts while also complying with DMARC when using Amazon SES. In order to do this, you set up a sending identity so that Amazon SES automatically adds a DKIM signature to your messages. Additionally, you created a custom MAIL FROM domain to comply with SPF. Lastly, you authorized another AWS account to send emails from a sub-domain managed in a different account, and tested this using a Lambda function. Allowing other accounts the ability to manage and send email from your sub-domains provides flexibility and scalability for your organization without compromising on security.

Now that you have set up DMARC authentication for multiple accounts in your enviornment, head to the AWS Messaging & Targeting Blog to see examples of how you can combine Amazon SES with other AWS Services!

If you have more questions about Amazon Simple Email Service, check out our FAQs or our Developer Guide.

If you have feedback about this post, submit comments in the Comments section below.