Mailgun FAQs

You recently sent an email campaign to a list of recent signups. When opening the Logs in the Mailgun control panel to check the campaign's status, you notice right away a lot of yellow-shaded entries with the following error: "498/499 No MX for [domain.tld]."

(Note: [domain.tld] is simply a placeholder value for the specific domain you will see in the error; usually it's a misspelling of a domain name, such as gmai.com, ahoo.com, or htomail.com).

At this point, you might start to panic - so many failures, and so much yellow! While this is certainly a reasonable response - you care about your sending, after all - we're glad to explain what this all means, and how to help achieve a solution.

Temporary Failures

The Logs will shade each event in either green (successful), yellow (temporarily unsuccessful), or red (permanently unsuccessful). For the Failed events that will display the 498 error, they will be shaded in yellow to indicate they are temporary failures.

Temporary failures enter a retry window where we'll automatically performa certain amount ofattempts over a certain time period. The most common retry window, hardcoded into our environment, is 8 hours, with retries at the following intervals after the initial delivery attempt:10 minutes, 10 minutes, 15 minutes, 30 minutes, 1 hour, 2 hours, and 4 hours. What if the message fails on every retry attempt during the retry window? The final Failed event will be shaded in red to indicate it is a permanent failure; no further retries for that send will be attempted.

What"498/499 No Mx for [domain.tld]" Signifies

Let's review this example: "498/499 No MX for yahoo.comm." In the Logs, you'll see this error actually consists of two fields:

delivery-status.code: 498/499

delivery-status.description: No MX for yahoo.comm

The underlying cause of the error is always DNS-specific. For this example, the domain yahoo.comm does not have any MX records assigned; it's a non-existent domain. When a domain lacks MX records, email servers do not know where to send emails to for that domain. There are tools available such as dig, MXToolbox, and WhatsMyDNS that can verify what DNS records (if any) are configured for a domain.

The primary reason a domain might be lacking MX records is that the domain simply doesn't exist. In our example above, the domain was mistyped as yahoo.comm rather than yahoo.com at some point during the email registration process for this recipient;this is part of why a double opt-in policy is so important.

Less commonly, there are two other reasons a domain may be lacking MX records: either a domain's DNS provider is experiencing an incident(as in, a temporary misconfiguration), or the domain's owner(s) has configured the MX records incorrectly (if at all). The former scenario will virtually always be a temporary setback; just an incident, resolved shortly. However, concerning the latter scenario, it is less certain as to if and when it will be resolved, since the domain's owner(s) must first become aware of the misconfiguration before they can thencorrect the misconfiguration.

Email Validation Is Your Best Friend

Since the two less common reasons for a domain lacking MX records are ultimately outside of the control of both you and Mailgun, let's focus on the one thing that is within your control: gatheringyour recipients' email addresses.

It is fairly certain that a list filled with addresses such as [email protected] or [email protected] has an underlying issue at the point of data entry. Whether a user directly enters information into a web form, or an employee manually records contact details from recently signed contracts,our email validation service can help! Some of the checks our email validation service performs can highlight when a domain lacks MX records or appears to be mistyped. Removing or correcting these addresses before sending will keep both your mailing lists and your Logs clean and pristine. It may seem obvious, but it's worth stating that this kind of due diligence has a massive effect on your mail's deliverability.

If any questions arise, just reach out to our Support team via the Supportoption in your Mailgun control panel!

You're looking to track your sending's engagement, so you've enabled click tracking. However, the click tracking links, for some reason, will not resolve. Not to worry - we have a few common troubleshooting tips to help get your links up and running.

Check CNAME

The first step we recommend is to make sure you have the CNAME record for the sending domain properly configured. The tracking hostname should return mailgun.org for the US region, or eu.mailgun.org for the EU region. This can be easily checked in a terminal using a dig command (Linux/Mac) or an nslookup command (Windows). If the terminal scares you, you can always use a web-based tool like MX Toolbox.

Note: The CNAME will not return if you've configured the CNAME as proxy/CDN, such as CloudFlare.

Dig:

$ dig -t CNAME email.domain.tld +short

Nslookup:

nslookup -q=CNAME email.domain.tld

You should receive the response "Mailgun Magnificent API" if you make an HTTP request to the base tracking hostname, like below:

$ curl -s http://email.domain.tldMailgun Magnificent API

Check HSTS

Mailgun currently only supports HTTPS tracking links via the use of a configured CDN; more information on that in this article. The source of your issue might be a combination of this element of our system with your settings relevant to HSTS. HSTS tells browsers to enforce HTTPS connections to the domain. This will result in the tracking links timing out. The following curl request will quickly confirm if HSTS is enabled:

$ curl -s -D- https://domain.tld/ | grep -i Strictstrict-transport-security: max-age=2592000; includeSubDomains; preload

You'll need to disable HSTS or use a different domain without HSTS for the tracking links to resolve. If you are unable to disable HSTS, or your use case requires HTTPS, you can check out the help article detailing the steps needed to enable HTTPS tracking links via the link above.

Check Original Links

Another element to check is verifying the original links are valid. The best way to do this is to grab the original MIME via either the API or the control panel, providing the message is less than 3 days old (the amount of time our system retains message bodies).

Inside theMailgun Control Panel(options displayed down the left-hand side on a dark column), use the following instructions:

ClickSendingon the left of your screen.

Select your specificdomain.

Click onLogs.

Search for the specific message-id in theblankon the right.

On the line of the specific log entry, click thethree-doticon. From its dropdown, clickMIME, and you should see the full MIME immediately.

Once you've obtained the MIME, you can inspect the links to see how they looked before they were rewritten to ensure the original links are valid.

Of course, if you are still having trouble with non-HTTPS click tracking links after trying all of the above, please do not hesitate to reach out to our Support team via the Support option in your Mailgun control panel!

This error (also called Sender Address Verification) occurs when the recipient server performs an MX lookup on the envelope.mail-from address and then fails to locate the MX records for the sending domain. (See this wiki for a deeper dive into the technical details of Sender Address Verification)

You might see this manifest in a few different ways; here are the most common:

550 Verification failed for <[email protected]>\nUnrouteable address\nSender verify failed

Domain of sender [email protected] does not exist

550 550 Verification failed for <[email protected]>

Unrouteable address Sender verify failed

Sender address rejected: User unknown in virtual mailbox table

452 4.5.2 Could not resolve sender domain

450 4.1.8 Sender address rejected: Domain not found

505 Your domain has no DNS/MX entries

550 550 Requested action not taken: mailbox unavailable invalid DNS MX or A/AAAA resource record

550 5.2.0 <[email protected]> From: Domain is invalid. Please provide a valid From: IB506 <http://x.co/srbounce>

550 550 5.7.1 Sender ID (PRA) Domain Does Not Exist

Now that we've seen the errors, We'll explore several ways to resolve this issue based on your current Mailgun sending domain.

Seeing This Issue With a Subdomain

When configuring any subdomain with Mailgun, while we don't require MX records to be used, as long as you don't already have incoming mail configured for the domain, we highly recommend pointing your MX records for the domain to Mailgun. Why? Doing so serves to proactively correct the Sender Verification Error issue before it begins - always good to be ahead of the curve!

As noted above, some pesky email servers check the subdomain in the envelope.mail-from field for MX records. If those records aren't found, then you're hit with a Sender Verification Error in your Mailgun logs. All is not lost, however - the fix is quite simple; just set the MX records for the subdomain to Mailgun values!

Once this is completed, the MX lookups of those email servers should be successful and the servers should accept your messages.

The two MX records for Mailgun that will need to be added to your subdomain are:

Value

Priority

mxa.mailgun.org

10

mxb.mailgun.org

10

Once the records have been added, you may need to wait the 24-48 hours for them to fully propagate; following this, the error should disappear.

If for any reason you're still seeing that same error, you can also try adjusting the From field of the message to match the sending domain as well.

Seeing This Issue With a Root Domain

What if you're using a root domain? In this case, your root domain already has your ESP's (Email Service Provider) MX records in place. The best and safest way to quickly resolve this would be to add a subdomain for your Mailgun sending instead.

When the subdomain is added, along with Mailgun's MX records configured for it, the error should be resolved!NOTE: Always make sure your MX records for a domain only point to one source. Otherwise, servers get confused, and bad things happen when servers get confused.

Alternate Approaches

Still having issues? Not to worry; here are the alternate options for resolving the error. Make sure to note - it's highly recommended to review and implement the above suggestions before moving on to these:

Turn off sender address verification (this is server-side with your email provider)

Create a catch all within the configuration of your email provider so that when the recipient server checks the sender information, verification it will pass

If any questions arise, just reach out to our Support team via the Support option in your Mailgun control panel!

In your Control Panel you can filter Logs by event type.

Accepted -Mailgun accepted the API request to send and the message was put in your queue.

Delivered -Mailgun sent the email and it was accepted by the recipient email server.

Opened -The email recipient opened the email and enabled image viewing. Tracking must be turned on.

Clicked - The email recipient clicked on a link in the email. Click tracking must be turned onand the CNAME record must be pointing to mailgun.org.

Unsubscribed -The email recipient clicked on the unsubscribe link. Unsubscribe tracking must be turned on.

Stored - The inbound email was successfully stored.

Rejected -Mailgun rejected the API request to send/forward the email.

Complained -The email recipient clicked on the spam complaint button and the recipient's email server provides feedback loops to Mailgun for these complaints.

Temporary Fail -Mailgun could not deliver the email to the recipient email server, but will retry. Usually due to soft bounces and ESP throttling.

Permanent Fail -Mailgun could not deliver the email to the recipient email server,and will drop the message. The common reason is we received a hard bounce or repeatedly received soft bounces

The Definition of a Route

You can think of our Routes feature as a sophisticated filtering and forwarding mechanism. With Routes, you have a good deal of capabilities at your disposal, such as:

Forward incoming emails to another environment for storage (such as another emailaddressor maybe an endpoint on your server)

Store a message temporarily (for up to 3 days) and retrieve it using our Messages API

Stop a message from being processed (this drops certain messages instead of forwarding or storing them)

The Creation of a Route

You can set up a Route in one of two ways:

Via the Mailgun control panel

Via the API

For brevity's sake, we'll just cover how to set up a Routevia the Control Panel in this article.

Inside theMailgun Control Panel(options displayed down the left-hand side on a dark column), use the following instructions:

Click on the Receivingoption on the left-hand side of your Mailgun dashboard.

Click on the specific region for which you would like to create a Route.

Click the greenCreate Route button in the top-right section of the control panel.

Fill out the information for the Expression Type, Actions, Priority, and Description field before clicking on the Create Route button to save the route.

The Features Of A Route

The first thing you will see is the Expression Type dropdown menu.This consists of the following expressions:

Catch All - Gives you a way to catch the incoming messages for which you've not made a specific Route

Match Recipient - This will filter any incoming messages that match a specific email address, such as [email protected] (where mail.example.com is the domain verified on your account)

Match Headers - Similar toMatch Recipient, this will filter incoming messages based on a header in the message, such as any message with the word "support" in the subject line

Custom - Custom routes are a little more advanced; this is where you can combine a multitude of filters to really get specific. If you want to learn more, check out the docs we have on our Routes here

Next, you will need to choose among a set ofActions.We mentioned these at the beginning of the article, but we'll repeat them here for convenience:

Forward forwards incoming emails to another environment for storage (such as another emailaddressor maybe an endpoint on your server).

Store and notify stores a message temporarily (for up to 3 days) where you can retrieve it using our Messages API. It also allows you to pass an endpoint or leave it empty, in which case we provide the storage URL for you to retrieve the message later via the Messages API.

Stop stopsa message from being processed (again, this drops certain messages instead of forwarding or storing them).

And finally, the last two fields arePriority andDescription.In the Priority field, you can specify a priority level to determine the sequence in which the Route gets handled. Here, the lower the number, the higher the priority. The lowest number would then be handled first; like a ranking of importance. In theDescription field, you can specify a description to either name or identify the Route. For instance, "Forward from subdomain1 to Alice at Example.com." This is just for your reference, to help you quickly identify just which route you're looking for.

If any questions arise, just reach out to our Support team via the Support option in your Mailgun control panel!

Mailgun customers send millions of emails per month, so finding the status of a specific email can be like finding a needle in a haystack.

We built the API to be highly performant, even across 10s of millions of log entries. To do this, we built the API on top of ElasticSearch, an open source framework for building real-time search and analytics.

Fields you can search across:

From address

To address

Recipient address

Event type

List name

Tag name

Attachment name

Message ID

Subject

Examples of some search queries you can run:

"foo bar" matches field values that contain both term "foo" and term "bar".

"foo AND bar"same as above.

"foo OR bar" matches field values that contain eitherterm "foo" orterm "bar".

""foo bar"" (with quotes) matches field values that literally contain "foo bar".

"@example.com" matches all from, to and recipients @example.com

tags:"your tag here"

Things to keep in mind:

We only store your events data for a certain numberofdays

Free accounts - 2 days

Paid accounts (with a credit card on file) - 30 days

Westore the raw MIME of the message for up to 3 days

Its up to you.

Touse Mailguns unsubscribe handling, you can include our unsubscribe variables %unsubscribe_url% (for the entire domain) and %tag_unsubscribe_url% (for just emails with this tag) and we will take care of the unsubscribe handling for you.

Take a look at our unsubscribe documentation for more information.

Yes. Mailgun tracks all of the typical events that occur with emails:

Opens

Link clicks

Bounces

Unsubscribes

Spam complaints

We make that data available to you via the Control Panel or through the API.

In addition, you can set up webhooks and we will post events to your URL. Take a look at our tracking documentation for more information.

Think of hard bounces like permanent errors and soft bounces as temporary errors.

We will stop attempting delivery after one hard bounce.

With soft bounces, we keep trying to deliver but eventually we will stop trying to delivery in accordance with the receiving ESPs feedback.

Creating a campaign and include its tag in your email. You can thenseewhich campaign is performing best by viewing the data grouped by tag.

This has been a popular question, so we wrote a blog post about it.

The Message-ID in the original email is included in the In-Reply-To header in the reply email. So you can use that to track which specific email was replied to.

Mailgun will automatically include a unique Message-ID or you can set your own.

Mailgun can make an HTTP POST to a callback URLwhen events occur with your messages.

Webhooks are at the domain level so you can provide a unique URL for each domain. We recommend using bin.mailgun.net for creating temporary URLs to test and debug your webhooks.

For Webhook POSTs, Mailgun listens for the following codes from your server and reacts accordingly:

If Mailgun receives a 200 (Success) code it will determine the webhook POST is successful and not retry.

If Mailgun receives a 406 (Not Acceptable) code, Mailgun will determine the POST is rejected and not retry.

For any other code, Mailgun will retry POSTing according to the following schedule (other than the delivery notification):10 minutes, 10 minutes, 15 minutes, 30 minutes, 1 hour, 2 hour and 4 hours.

You can find our webhooks manual here.

Currently, Mailgun doesn't officially support HTTPS tracking links. Not to worry though - there is a workaround! It does require the use of a CDN, and we recommend utilizing CloudFlare. However - most CDNs should suffice.

Why Do I Need a CDN?

To understand why the use of a CDN is required for HTTPS tracking links, here's a quick, high-level overview of how they work is needed.

Tracking links work by utilizing a CNAME that points to mailgun.org. Links in your email messages are then rewritten with this tracking hostname. When your recipients then click on those links, it first sends the request to mailgun.org,and we return a redirect to the original URL.

Since we do not support HTTPS connections to mailgun.org, a CDN is needed to fill the gap between the client and mailgun.org. Essentially, the client connects to the CDN via HTTPS, the CDN connects to mailgun.org via HTTP, and the CDN relays the response from mailgun.org to the client over HTTPS.

The following are the specific steps for setting up CloudFlare as a CDN to handle Mailgun tracking links to support HTTPS.

Step 1 - Create a CNAME

In your CloudFlare account:

Click on the DNS option and configure a new CNAME entry that points your Mailgun Tracking CNAME (e.g., email.your-domain.com ) to mailgun.org. Ensure that the CNAME is configured as DNS and HTTP Proxy (CDN). The cloud image under Status should be the color orange.

Step 2 - Create a Page Rule

Navigate to the Page Rules settings for your domain and create a Page Rule for your Tracking CNAME (i.e., email.your-domain.com ) settingSSL to Flexible. Make sure to use a wildcard after your domain for the best results (e.g., https://email.your-domain.com/* ).

Turn this toOn.

Step 3 - Create a Support Ticket

Once the above 2 steps are done, create a Support ticket via the Support tab of the Mailgun control panel to let us know. We will then set your links to default to HTTPS instead of HTTP.

Note: CloudFlare's default universal SSL certificate only supports root and 1st level subdomains. If your tracking hostname is a 2nd level domain or higher, you'll need to contact CloudFlare to discuss your options for an SSL certificate to support the tracking hostname.

If any questions arise, just reach out to our Support team via the Support option in your Mailgun control panel!

Open Tracking is an essential feature used to gauge user interaction with and response to your email campaigns. Ensuring this feature is working as intended is key to obtaining accurate statistics for your emails.

How It Works

Before we get into diagnosing issues that can occur with Open Tracking, we need to know how tracking actually works.To track Open events, the email must meet the following criteria:

The sending domain must have the tracking CNAME in place

The email must contain HTML content

The recipient must be able to load images in the email

The domain or email must have tracking enabled

The email can contain a Tag (optional)

When a message is submitted through Mailgun, an invisible 1x1 pixel image is embedded into the body of the message. This image performs a request to our server, logging the recipient's tracking information in your domain's Mailgun logs. Additionally, a Tag may be used to help our system aggregate the statistics for a specific email campaign or service (i.e. sign-up, password resets, billing notifications) within your platform. It is important that the image loads on the recipient's side in order to capture the tracking data.

Troubleshooting

Tracking can be enabled in 3 different ways:

1. Global tracking settings are found in the domain details page of the Mailgun control panel.

Inside theMailgun Control Panel(options displayed down the left-hand side on a dark column), use the following instructions:

Click onSendingon the left of the screen

Select yourdomain name

Click onDomain Settings

Scroll down toOpen tracking, where you'll then click onEditall the way to the right.

NOTE: If the tracking CNAME is not properly configured, the option to edit the Tracking options will not be available. See our DNS troubleshooting guide for assistance.

2. Add the Open tracking parameters with an API request; or 3. Add Open tracking headers to the MIME body when sending via SMTP.

NOTE: The tracking headers/parameters have precedence over the global domain settings. This is helpful if you wish to only track a specific group of messages.

Sending via our API

o:tracking = yes - Enable both Open and Click Tracking

o:tracking-opens = yes - Only enable Open tracking

Sending via SMTP

X-Mailgun-Track: yes - Enable both Open and Click Tracking

X-Mailgun-Track-Opens = yes - Only enable Open tracking

Tracking Is Enabled; Still Not Receiving Opened Events

There are 3 main points to review when Open tracking is not resolving:

The Tracking CNAME is no longer setup correctly or resolving publicly. This can be confirmed via a dig or nslookup query from your computer or a public DNS tool like What's my DNS. If the CNAME hostname does not return the value "mailgun.org", then the record would need to be updated at your DNS hosting provider.

The email does not contain an HTML body. The tracking image cannot be embedded on a text-only email. To resolve just update your email's template to include HTML content.

By default, our tracking links do not support forced HTTPS redirects. If your domain forces HTTPS redirects via HSTS or other similar methods, then the tracking link cannot finish the callback to our server. See our article on HTTPS tracking for assistance.

If any questions arise, just reach out to our Support team via the Support option in your Mailgun control panel!

To manage your domain's inbound spam filtering settings you will need to navigate to the Domain Settings page for your domain.

Inside theMailgun Control Panel(options displayed down the left-hand side on a dark column), use the following instructions:

Click onSendingon the left-hand side of your Mailgun dashboard.

On the following page click on your specific domainand click on Domain Settingson the far right-hand side.

UnderDomain Settingsthe optionInbound spam filterwill be available.

To change these settings, click on Edit.

Choose your preferred Spam filtering option and clickSave Spam Settings.

We provide 3 different methods for processing inbound spam:

No filtering (this is the default setting)

Block detected spam (this is recommended)

Deliver spam, but addX-Mailgun-SFlag and X-Mailgun-SScoreheaders.

If you are using our Routes feature to handle inbound email requests, it is highly recommended that you select option 2 -Block detected spam.

Inbound messages that are being routed to an email address or POSTed to a URL will pass through our outbound spam filters, so If you choose not to enable inbound spam filtering, spam messages that are sent to you may get caught inour outbound spam filter, resulting in your domain being disabled. This is why we recommend option 2.

Note: You need to add Mailgun MX records for inbound messages.

If any questions arise, just reach out to our Support team via the Support option in your Mailgun control panel!

There is no 100% guarantee. However, there are some good clues.

Mailgun provides DKIM and SPF verification for incoming mail, which is shown in the MIME headers once spam filtering is enabled in the Control Panel. This way you can at least know if the message is coming from an authenticated server.

Mailgun allows you to check the authenticity of its requests by providing three additional parameters in every HTTP POST request it makes.

Please take a look at our webhooks documentation for more information.

Youre most likely using GMail for sending your message. See GMails documentation.

If youre sending mail to a mailing list that you subscribe to, those messages will only appear in Sent Mail. This behavior also occurs when sending to an email address that automatically forwards mail back to your Gmail address. To test forwarding addresses or mailing lists, use a different email address to send your message.

When a message from [email protected], for example, goes through a route:

[email protected] -> [email protected]

When this message arrives to GMail, it will have [email protected] as both sender and recipient, therefore GMail will not show it.

In other words GMail does not show you messages you sent to yourself.

The other possibility is that the address had previously experienced a Hard Bounce and is on the do not send list. Check the Bounces tab for a list of these addresses and remove the address in question if it is there.

Its not recommended.

There are plenty of hosted email services better suited for this than Mailgun; Rackspace Email, Gmail / Google Apps, Outlook, etc.

Mailgun is meant to be a tool for developers and their applications.

"Help! I can't get my routes to work!", you exclaim! Never fear, help is here!

Our Routes can be used in many different ways, this also means that there are multiple things that can cause a bump in the road.

Common Things to Check:

Does the Route match the domain name of one of your domains tied to the account?

Do you have your MX records for your domain pointing to Mailgun?

Do you have any spelling errors in your route?

Sidenote:if your domain or subdomain already has MX records in it's DNS pointing somewhere other than Mailgun, we do not recommend that you make any changes. What we do recommend setting up a different domain in Mailgun to use your routes with because multiple MX records on one domain can cause some issues with receiving emails. Youdon'twant to end up missing anything important!

Also, you can always take advantage of our Routes Tester in the Control Panel to test which route an email address would trigger if someone were to send to it:

If you have your MX records properly configured, though, and the route is still not firing, then something may be wrong with the route itself.

We support a few different actions to take on incoming messages and these can all be configured on the Route settings page for your route. If your custom route is not triggering properly, you may want to refer back to our Mailgun Docs centered around Routes:

https://documentation.mailgun.com/en/latest/user_manual.html#routes

That's just about it on debugging and debunking and troubleshooting your Routes! Hope we could clear things up! :)

What is Inbox Placement and why should I use it?

Inbox Placement provides an easy way to test an emails deliverability before sending your campaign.

While your email may have been successfully delivered, theres no great way of knowing if it actually landed in the inbox. Inbox Placement takes the guesswork out of deliverability, giving you a better indicator of whether your message will make it into the inbox, the spam folder, or in the case of Gmail, which folder/tab the email was placed.

While metrics like delivery rates, open rates, and click rates can only be obtained after sending out an email campaign, inbox placement gives you a chance to test performance before you send, without wasting time and money if your campaignisn'tlikely to make it to the inbox.

How is Mailguns Inbox Placement product different?

As an email service provider (ESP), Mailgun simplifies your email marketing workflow and provides a comprehensive assessment of how to improve your inbox placement / deliverability rate by aggregating inbox placement insights with historical sending metrics and email engagement data.

By sending billions of emails every month, we can dynamically weight your seed testing results based on historical email sending through Mailgun instead of requiring you to manually weight your results.

Is seed data the same as panel data?

No. Panel data is comprised of thousands or even millions of crowdsourced mailboxes that belong to individual users. Its advocates argue that this large data set allows for an accurate representation of where email will land.

Seed data, on the other hand, is comprised of scores or hundreds of mailboxes thatdon'tbelong to individual users but rather, are managed by the seed test provider and reflect neutral usage in most cases.

Mailguns platform does not use panel data. Not only does panel data leverage personal mailbox information, but policy changes in recent years essentially make the use of panel data obsolete.

Which Mailgun plans offer the Inbox Placement feature?

During beta, Inbox Placement is available to all accounts that have been granted access, regardless of plan.

How often should I run a seed test? Should I run the same test multiple times?

There are a few different variables you can use to determine the best frequency of running inbox placement tests, and it mostly depends on your goals and objectives.

If you make changes to your template or copy, we advise waiting at least 15 minutes between tests due to the possibility of mailbox provider-induced delays. To see the effects of those changes on your deliverability, run a new test each time you tweak a campaign.

If you want to see how your current reputation affects your deliverability, we suggest running one test and then waiting untilyou'veaddressed any factors impacting your reputation before running another test. Since improving your reputation takes time, you may want to wait at least 30 days from when you made those adjustments before re-running a test.

If you are trying to determine if mailbox provider algorithms are changing and impacting your inbox placement rate, we recommend running inbox placement tests weekly as a general best practice to keep tabs on any fluctuations in your deliverability.

Which mailbox providers are included in the seed list?

The seed mailboxes currently offered are based on the most common providers we see across the billions of emails Mailgun sends each month. We dynamically weight your seed testing results based on historical email sending through the platform, rather than requiring you to manually weight your results. You can find the full list of seed addresses within the Seed List section of your control panel.

Why am I seeing countries in the seed list I don't send to?

Since we consider Inbox Placement a proactive tool, Mailgun will, by default, run your inbox placement test against our entire list of seed mailboxes, which may include mailbox providers in countries that youdon'tcurrently send to but might start sending to in the future. We see this as a benefit as you will start to compile a running history of inbox placement rates that you can leverage at a later point in time. Plus, by sending to a broader list of providers, you will get a better assessment of your inbox placement rates at a global level.

Can I filter my results only to certain providers?

Currently, you cannot filter results to certain providers. That said, we have plans to provide an easier way to filter down your seed list in future iterations of the product.

Whats the difference between Inbox, Missed, and Spam?

In the control panel, you will notice that your inbox placement rates will be divided into three categories Inbox, Missed and Spam. Emails categorized as Inbox were placed in the inbox by the mailbox provider. Items marked as Missed did not make it into the mailbox. Emails marked as Spam were delivered to the spam or junk folder.

Does Inbox Placement support EU domains?

No. Currently, you may only create seed tests with non-EU domains.

Is the seed list static or is it generated each time I create a test?

The seed list is a static list. That said, we are adding new mailboxes over time so you may see the seed list grow as we extend support to more mailbox providers.

Absolutely. Ideally, you send email that people want. Thats over half the battle. In addition, you should make your content interesting and relevant to the recipient.

There are a few things to keep in mind about your email content. First, we suggest setting up a test mailbox at Mail-Tester. Mail-Tester will provide you with a full analysis of your email for free. Here are some other things to consider:

Personalize your emails. Make sure to include the recipients address in the To: field and include his/her name in the greeting.

It is best to send multi-part emails using both text and HTML or text only. Sending HTML only email is not well received by ESPs. Also, remember that ESPs generally block images by default so HTML only will not look very good unless users are proactive about enabling images.

Test how your html email looks across all email clients and browsers. Litmus and Return Path have tools to do this.

Make your content relevant and targeted to the recipient. There are even tools like Movable Ink that let you dynamically update your content after it is delivered.

The higher the text to link and text to image ratios, the better. Too many links and images trigger spam flags at ESPs.

Misspellings, spammy words (buy now!, Free!) are big spam flags, as are ALL CAPS AND EXCLAMATION MARKS!!!!!!!!!!!!!

The from field in your emails should match the domain you are sending from. Hotmail is particularly focused on this.

Make sure you are using unsubscribe links and headers in your emails. Many ESPs (particularly Hotmail) pay attention to this and if they are not there, you are likely to get filtered. You can always use Mailguns auto unsubscribe handling if youdon'twant to deal with this on your end.

Include your physical mailing address. CAN-SPAM requires an unsubscribe link and a physical mailing list. It is also a good idea to provide a link to your privacy policy.

Gmail pays particularly close attention to Message ID and Received headers. Message IDs that are formed incorrectly (without brackets <> and with wrong domain after @) can make Gmail think you are a spammer. The simplest way to create the right Message ID is to not set Message ID at all. Then Mailgun will create a perfect Message ID for you. Also, if you use the HTTP API, Mailgun will deal with all of this for you.

Links should include the domain that is sending the email. Also, popular url shorteners can be a bad idea because they are frequently used by spammers.

A/B test your emails to optimize recipient engagement. Subject lines are particularly important. You can use Mailguns tagging and tracking statistics in order to measure A/B testing and improve your content.

Do you feel the need to secure the API access to your account? Well so do we! Because of this, we've implemented the IP whitelist settings, where you can specify the IPs that have permission to access the API. When utilizing the IP whitelist,only the IPs you have specified will be able to connect to the API.

Note: this will not impact SMTP connections.

How to Enable IP Whitelist?

To enable the IP Whitelist, just follow the steps below:

Inside theMailgun Control Panel(options displayed down the left-hand side on a dark column), use the following instructions:

Click onSettingsin the lower left-hand side of the Mailgun control panel, then clickSecurity & Users.

Select the API security tab option.

Scroll down toIP Whitelist, then click the greenAdd to Whitelistbutton on the right.

You will then be prompted to enter the IP / CIDR information; then just click Save IP Address / CIDR.

That's it - you should be all set! While an important and highly effective way to secure your account, it is actually really quite simple to add and remove IPs from the IP whitelist.

If any questions arise, just reach out to our Support team via the Support option in your Mailgun control panel!

Curious about the status of a specific message? Want to know why a certain message failed, or when the Failed event occurred? All this can be yours when you've got a Message-ID!

What Is It?

The Message-ID functions as a unique identifier for the messages being sent. The ID will be composed of a randomly generated string as well as the sending domain or host (similar to an email address in most cases; e.g. [email protected]). Moreover, the Message-ID is unique to that exact message itself, whether the message contains one or multiple recipients. Even if two messages are sent back to back, their Message-IDs will not be the same, as long as our system is generating the Message-ID. (Reference: https://en.wikipedia.org/wiki/Message-ID )

Why Should I Care?

Well, theMessage-ID is the most efficient method for viewing all the events associated with a specific message. For example, if you are viewing an Accepted event in your logs for a specific message and you want to see when/if a successful Deliveredevent was returned, simply grab the Message-ID from the Acceptedevent and enter it into the search box within your Logs inside the Mailgun Control Panel (more details below). This will return ALLevents associated with that specific message, allowing you to view the status of the message, as well as the exact time each event occurred.

How Do I Find It?

Inside theMailgun Control Panel(options displayed down the left-hand side on a dark column), use the following instructions:

Click on the Sendingoption on the left-hand side of your Mailgun dashboard

Click on the specific domain name for which you'd like to view the Logs.

You will click on theLogsoption.

Scroll through the various events until you find the event you would like to review.

Once the event is located, click the downward-pointingicon all the way to the right of the log entry, which will reveal additional metadata (envelope and header information) for the message.

The message-id field will be listed among this additional event data (the message headers data near the bottom of the metadata), next to the header title of the same name.

Pro-Tip:Whenever you submit a support ticket regarding a specific message or set of messages, it is always a good idea to provide Mailgun Support with the related Message-IDs. This speeds up our investigation, getting you back in action faster!

If any questions arise, just reach out to our Support team via the Support option in your Mailgun control panel!

Suppressions are a mechanism Mailgun utilizes to help ensure the protection of your domain's reputation, as well as the reputation of our IP's. Specifically, this is all about internally preventing delivery to addresses that have been demonstrated as problematic for various reasons.

Since they've been proven to encounter issues with receiving mail from your domain in a way you certainly don't want repeated, we internally block sending to these addresses so they don't harm your ability to keep sending. Without Suppressions to prevent further sending to these particular addresses, your domain would run into AUP violations such as high bounce and complaint rates, severely damagingyour email deliverability; exactly what wedon'twant!

How are Suppressions Organized?

Suppressions are organized per domain, since they're based on the proven interaction with a specific send. To view Suppressions, you can either use the Mailgun control panel or view programmatically through the relevant APIs (see below, under Types of Suppressions). In addition to just viewing your currentSuppressions, you can add/delete single addresses, or even entire groups of addresses.

Inside theMailgun Control Panel(options displayed down the left-hand side on a dark column), use the following instructions:

ClickSendingon the left of your screen

Select your domain name

Click onSuppressions. Youcan either view all Suppressions for that domain by default or search for a specific address via the blank on the right.

Types of Suppressions

There are three types of Suppressions; Bounces, Unsubscribes, and Complaints.

Bounces - These aren't just any bounces/failures; rather, these are those bounces that specifically happen due to a recipient's address being returned as invalid/non-existent/temporarily misconfigured.

When the viewing the Bouncesportion of the Suppressions page in the Mailgun control panel, the page will list the address, the date the bounce occurred, and the error message the recipient's email server returned that prompted our system to add the address. This way, you see exactly why the address was added to the list. You can also pull these results via the API: https://documentation.mailgun.com/en/latest/api-suppressions.html#bounces

Unsubscribes - Pretty simple; when a recipient no longer wishes to receive emails, and has clicked to unsubscribe.

WithUnsubscribes, the Suppressions tab will list the address, the date the unsubscribe was received, and the details such as "*" for a domain-wide unsubscribe or a specific Tag value for a campaign-based unsubscribe. (Note: subscription status of a member in a Mailing List is indicated in the Mailing List section of the Control Panel). Or, you can use the API: https://documentation.mailgun.com/en/latest/api-suppressions.html#unsubscribes

Complaints - Also simple; when a recipient complains about your sending by clicking to mark it as spam in their inbox.

Finally, for Complaints, the Suppressions site will listthe address and the date the complaint was received; the details column is not used for complaints. To use the API, look here: https://documentation.mailgun.com/en/latest/api-suppressions.html#complaints

Best Practices

As addresses are added to your Mailgun Suppressions, we highly recommend regularly removing those addresses from any contact lists you maintain. This will ensure that you are no longer sending to these addresses through your sending application. To be clear, the addresses should be removed from your contact lists - wherever they may be stored (e.g. CRM, database, file, etc) - and not from the Mailgun Suppressions. If you just remove the addresses from Suppressions list in Mailgun, and not from your contact lists, the process starts over, and you're again risking damaging your reputation.

For other best practices such as our list management practices, subscribe handling practices, and feedback loops and spam complaints practices, please see our Email Best Practices documentation. Additionally, you may also want to consider using our excellent email validation service to ensure your lists are not overflowing with invalid email addresses from the start. This way, you're using Suppressions in the most effective way possible. Always best to stay ahead of the game!

If any questions arise, just reach out to our Support team via the Support option in your Mailgun control panel!

Ever received an avalanche of email from someone? Not exactly what you might call the most enjoyable experience.When this happens, we naturally might get tired of the sheer volume of emails and want to unsubscribe. But what if the unsubscribe is ignored, or there isn't even a clear way to unsubscribe in the first place? Perhaps you're just fed up and want to end this madness right now? You'll likely simply mark the message as spam to make a clean break.

Unbeknownst to you, that's exactly what your customer, Tim the Enchanter, did. Tim received a ton of Black Friday emails from you this year and decided that enough is enough; spam button pressed! During your yearly Black Friday sale, you notice that sending to Tim is now encountering issues. Being a savvy Mailgun user, you check your Mailgun Logs (or alternate monitoring method), and you notice Tim's email failed with the message"Not delivering to a user who marked your messages as spam."

So, what does this error mean; can Tim the Enchanter still receive emails from you? Don't worry - we'll explain everything you need to know below!

TL;DR Overview

If the recipient marks your message as spam, the rule is that you need to honor their decision of strongly rejecting your emails. The exception, however, is either if the recipient specifically reaches out to you stating the complaint was made in error, or if the recipient later opts-in to receive emails once again. In these specific cases, the recipient should opt-in once again to your emails and you may then remove their address from the Mailgun Suppressions list. Removing the email address from the Suppressions list of the Mailgun Control Panel will allow delivery of new messages to said address.

The Cause

This error indicates that the email address is currently suppressed by our system from further delivery attempts. Why? Because sometime after receiving one of your emails, the recipient decided they no longer wish to receive any further emails from you, so they marked the message as spam or junk in their email application. When the recipient takes this action, their email provider generates a complaint and sends it to the sender's email provider (in this case, Mailgun). When this happens, we suppress the address internally to protect the reputation of your domain, and that of our IPs. Additionally, we do this to comply with international laws and regulations.Sending to recipients who no longer wish to receive emails possibly violates numerous laws and regulations and severely damages your deliverability; this is spammer behavior, after all.

The Solution

The solution depends on the reason behind the cause: did the recipient intentionally or unintentionally complain about your messages by marking them as spam? Nearly always, the recipient's complaint is intentional. As such, you really shouldn't just remove their address from the Suppressions; you need to stop emailing them any further. (An important point: if the recipient opts-in to receive your emails once again at a later date, their address can be removed from the Suppressions list). In some seldom-seen cases, the recipient's complaint is unintentional. When this happens, if they reach out to you explicitly stating the complaint was unintentional, the recipient should opt-in once again to your emails while you remove that recipient from the Suppressions.

In the case that removing the address from Suppressions is warranted, you can remove them from the list via your Mailgun control pane, or via the Complaints API, using an HTTP DELETE request.

Inside theMailgun Control Panel(options displayed down the left-hand side on a dark column), use the following instructions:

Click on the Sendingoption on the left-hand side of your Mailgun dashboard.

Click on the specific domain for which you would like to view the Suppressions.

You will click on theSuppressions option.

Choose the Complaints suppression type, and then click Delete button on the right-hand side of the specific suppression you would like to delete.

Lastly, to read more about Suppressions, please see this related help article. If any questions arise, just reach out to our Support team via the Support option in your Mailgun control panel!

You send a ton of email because you sell a lot of goods and services. However, you notice that one of your best customers, Arthur (King of the Britons), is no longer purchasing anything during your sales promotions. Being a savvy Mailgun user, you look inside your Mailgun Logs (or alternate monitoring method), andyou notice Arthur's email failed with the message "Not delivering to unsubscribed address."

What does this error mean, and can Arthur (King of the Britons) still receive emails from you? Don't worry; we'll explain everything you need to know below!

TL;DR Overview

If the recipient unsubscribed, the rule is that you need to honor their decision of unsubscribing from your emails. The exception, however, is either if the recipient specifically reaches out to you stating the unsubscribe was made in error or if the recipient later opts-in to receive emails once again. In such cases, the recipient should opt-in once again to your emails, and you may then remove their address from the Mailgun Suppressions list. Removing the email address from the Suppressions list of the Mailgun control panel will allow delivery of new messages to said address.

The Cause

This error indicates that the email address is currently suppressed by our system from further delivery attempts. Why? Because at some point, after receiving one of your emails, the recipient decided that she or he no longer wished to receive those emails, and as such, unsubscribed from your mailing list. Due to this, we suppress the address to protect the reputation of your domain, and that of our IPs. Additionally, we do this to comply with international laws and regulations.Sending to recipients who no longer wish to receive emails possibly violates numerous laws and regulations and severely damages your deliverability; this is spammer behavior, after all.

The Solution

The solution depends upon the reason behind the cause: did the recipient intentionally or unintentionally unsubscribe? In the overwhelming majority of cases (i.e. virtually always), the recipient's unsubscribe is intentional; as such, you really don't want to remove their address from the Suppressions, and you need to stop emailing them any further. (An important point: if the recipient opts-in to receive your emails once again at a later date, their address can be removed from the Suppressions list). In the overwhelming minority of cases (i.e. virtually never), the recipient's unsubscribe is unintentional; as such, if they reach out to you explicitly stating the unsubscribe was unintentional, the recipient should opt-in once again to your emails while you remove that recipient from the Suppressions.

In the case that removing the address is warranted, you can remove the address from the Suppressions list (or via the Unsubscribes API using an HTTP DELETE request).

Inside theMailgun Control Panel(options displayed down the left-hand side on a dark column), use the following instructions:

Click on the Sendingoption on the left-hand side of your Mailgun dashboard.

Click on the specific domain for which you would like to view the Suppressions.

You will click on theSuppressions option.

Choose the Unsubscribes suppression type and then click Delete button on the right-hand side of the specific suppression you would like to delete.

Simply mark the checkbox next to the recipient and use the delete button to remove the suppression. Once removed, new messages that you send to the recipient will attempt delivery, rather than being suppressed.

Finally, to read more about Suppressions, please see this related help article. If you have any questions, please open a Support ticket via the Support option of your Mailgun control panel- our team will be happy to assist!

It's 5 o'clock somewhere, and your business associate Sir Not-Appearing-In-This-Film calls you in a panicked state saying they never received an email you promised earlier that day. Being the savvy Mailgun user you are, you look inside your Mailgun Logs (or alternate monitoring method),and you notice his email failed with the message "Not delivering to previously bounced address."

So, what does this error mean, and how can Sir Not-Appearing-In-This-Film begin to receive your emails once again? Don't worry; we'll explain everything you need to know below!

TL;DR Overview

Removing the email address from the Suppressions list of the Mailgun Control Panel will allow delivery of new messages to said address, as long as the address no longer has any issues.

The Cause

This error indicates that the email address is currently suppressed by our system from further delivery attempts. Why? Because during a previous delivery attempt to this mailbox, the recipient's email provider returned an error to us indicating that the mailbox/email-address does not exist, or is invalid for some reason. As such, we suppress the address to protect both your and our sending reputation. High bounce rates negatively impact sending reputation, which in turn lessens your chances of optimal deliverability significantly.

The Solution

If the recipient's email address actually exists and any underlying issues with their mailbox have been fully addressed, you can remove the address from the Suppressions list (or via the Bounces API using an HTTP DELETE request).

Inside theMailgun Control Panel(options displayed down the left-hand side on a dark column), use the following instructions:

Click on the Sendingoption on the left-hand side of your Mailgun dashboard.

Click on the specific domain for which you would like to view the Suppressions.

You will click on theSuppressions option.

Choose the Bounces suppression type and then click Delete button on the right-hand side of the specific suppression you would like to delete.

Simply mark the checkbox next to the recipient and use the delete button to remove the suppression. Once removed, new messages that you send to the recipient will attempt delivery rather than being suppressed.

Please note, however, that if there is still an issue with the recipient's mailbox or if the email address is invalid, the delivery will fail and the address will be added to the Suppressions once again. In such a case, the recipient will need to address the underlying problem concerning the mailbox with their email host so that future delivery can be successful. Alternatively, if the mailbox simply doesn't exist, do not remove the email address from the Suppressions.

Finally, to read more about Suppressions, please see this related help article. If you have any questions, please open a Support ticket via the Support option of your Mailgun control panel- our team will be happy to assist!

Why indeed? As it happens, this is quite a tricky question, since there are several variables at play. Getting your messages delivered to the spam folder can be really, really frustrating, but don't despair: you're not alone. From our extensive experience with successfully delivering right into inboxes,we've got some tips for you. Put these practices into action, and watch how quickly your delivery results improve!

To set the scene, a primary reason your messages are getting sorted into spam is the sorting and filtering processes of the recipient's mailserver.The options are limited to correct this solely from the Mailgun side, but you can implement the following to empower your sending's potential:

Have Recipients Safelist Your Domain

If the reason why your messages are being delivered to a recipient's spam folder is due to the server's settings, the quickest way to bypass this would be to invite your recipients to safelist your sending domain (found in your Mailgun control panel - make sure it's the exact one!). You could also have the recipient safelist the sending IP, however, this is really only advisablewith a dedicated IP, since shared IP assignments are essentially dynamic; theycould be changed automatically by our system without notification. Safelisting the sending IP should only ever be a secondary option to safelisting the sending domain!

Check Message Content

Spam filters take a large number of things into account that we simply aren't able to see, due to their security protecting their environment and users. What is well-known concerning these filters is thatmessage content is extremely important.This is one element of the spam filtering puzzle over which you have direct control to help improve inboxing! The best way to determine what might be flagged in your messages would be to review them through a 3rd-party application to test just how "spamtastic" your content is in its current form, and what you can do to improve it.

Check DMARC Compliance

DMARC is very often a key element in the sorting mechanisms of ESPs (Email Service Providers). DMARC is all about ensuring the authenticity of a message and preventing spoofing. It helps demonstrate that a message has been protected by SPF or DKIM records; or, in the case of messages sent via Mailgun, both! However, it also indicates what should happen to a message if it does not pass the DMARC check - either mark it as spam, or reject the message completely! To ensure your messages pass the DMARC check with flying colors, you'll need to make certain the domains listed in the From, Sender, and Mail-From headers match each otherexactly. That is, the domain listed in the From header is theexact actual sending domain.

For example, if your sending domain is ABCdomain.com, but your From field shows 123domain.com instead, you will almost certainly run into DMARC issues. Sometimes, even the difference betweenmail.ABCdomain.com andABCdomain.com is sufficient for a server to place your message in a spam folder.We make sure that our Email Best Practices are clear that the domain listed in the From header and the actual sending domain should match for exactly this reason.

Additional Resources

Lastly, we have a plethora of articles that are devoted to helping you improve those inbox rates; be sure to check them out! Here's a sampling that should get you started:

http://blog.mailgun.com/art-of-inboxing/

http://blog.mailgun.com/how-to-deliver-email/

http://documentation.mailgun.com/faqs.html#if-i-m-just-starting-to-send-mail-how-do-i-build-a-good-reputation

http://documentation.mailgun.com/faqs.html#does-the-content-of-my-email-matter-for-deliverability

http://documentation.mailgun.com/best_practices.html

https://www.mailgun.com/blog/gmails-promotions-tab-how-to-get-emails-classified-as-primary

https://www.mailgun.com/blog/domain-ip-reputation-gmail-care-more-about

If any questions arise, just reach out to our Support team via the Support option in your Mailgun control panel!

A blacklist, alternatively called a DNSBL (DNS blacklist) or RBL (Realtime Blacklist), is a spam blocking list that can prevent a mail server from sending email.

Where Should I Check for IP Blacklisting?

There are hundreds of DNSBL sources across the internet, which can cause confusion about which actually affect email deliverability. The following major DNSBL providers are monitored and considered reputable by us and other services:

SpamHaus - One of the largest and most reputable DNSBL. SpamHaus is used by the majority of ISPs and email service providers.

SpamCop - A DNSBL which is based off reports by SpamCop users.

Barracuda Reputation Block List - Open source DNSBL service.

Invaluement - A IP and domain subscription based anti-spam blacklist.

How Can I Detect If Delivery Is Affected by a Blacklist?

Mailgun provides event logs for tracking for each message sent through our service. The event logsare available by logging into the control panel and viewing the Logs (Sending > choose your domain > Logs). Alternatively, event logs can be requested through our Events API.We will provideFailed events when an email could not be delivered to the recipient email server. Clicking the log event will expandthe view for more details of the event.

I Detected Failures Due to Blacklisting. What Are the Next Steps?

First, it's highly probable we've already processed the delisting, and are awaiting confirmation of removal from the DNSBL; we have an excellent and highly proactive AUP team monitoring all aspects of our system constantly. Each DNSBL processes removal differently and vary in time range.

To check on the status, or request further investigation of a failed event, contact our Support team via the Support tab in your Mailgun control panel,and please include the full details found in your Logs.

The way to think about your email reputation is much like your credit score. When you havent sent any email, youdon'thave a bad reputation but youdon'thave a good one, either.

No ESP is going to allow you to send a million emails to their mailboxes, much like no one is going to give you a credit card with a huge credit limit when you graduate from college. There needs to be a history of performance for you to create a reputation.

We use algorithms for our new senders that automatically queues your email and sends them at rates that makes the ESPs happy, increasing those rates as your sending reputation grows.

Some of the factors that help you build a good reputation faster and increase deliverability are:

Limited spam complaints and bounces.

Including the ability for recipients to unsubscribe.

Recipients interacting with your emails in a good way: reading, replying, forwarding and adding your addresses to their contacts.

Following ESPs guidelines on sending rates.

Paying attention to ESPs feedback to slow or stop sending for a period of time.

Having good content (see below for more guidance on content).

Also, consider letting your users to reply to your emails. Having a meaningful email conversations with your audience will do wonders for your reputation as a member of email community.

Finally, there are certification and white label services that can help (although, you still need some history of sending). We have a partnership with Return Path and get help get you signed up for their Email Certification Program. They have already audited our infrastructure so we can get you a discount off of their list pricing.

You can, but remember that your reputation is tied to your domain name as well as the IP address.

If you are in danger of being classified as a bad sender of email, you will be affecting your domain reputation, which is very hard to recover from.

It may be safer to use a completely separate domain (not a subdomain of your primary corporate domain) for sending marketing or even transactional email if you are worried about issues with domain reputation.

Rate limiting allows ESPs proper time to process and filter spam and ensure that transactional email doesnt get backed up. Without rate limiting in place, ESPs would be even more overwhelmed than they already are.

The ESPs all have different sending limits on a per hour, per day basis. Once you hit thresholds with the rate limits, send too much spam, or have any number of other issues, the ISP may start returning error messages.

Some ESPs will want you to slow down the sending, stop sending for a period of time, or change your habits (due to bad engagement, bad reputation, etc). We automatically adjust your sending rates according to the feedback from these ESPs to keep you in their good graces.

Generally, these rate limits are on a per IP address basis. Contact our Support Team if you wish to purchase additional dedicated IP addresses for your account.

Yes.

Generally speaking, youdon'twant too few IPs, in case you experience more volume than you expect and youdon'twant so many IPs that you look suspicious or spread out your volume over too many IPs.

There has to be a balance of volume to IP/domain. Sending too much volume from an IP, sending from too many IPs or sending too little from a range of IPs can all lead to deliverability issues.

One of the best resources is the blog Word to the Wise. Also, Return Path is a service that enhances deliverability and they publish a lot of great information through their blog and white papers. Below is are some best practices from the major ESPs.

AOL Best Practices

Gmail Best Practices

Hotmail Best Practices

Yahoo Best Practices

Follow this checklist to best optimize your emails for deliverability and avoiding the spam folder.

Addyour own custom domain and ensure DNS is setup and verified.

Utilize a double opt-in subscription model.

Always comply with the CAN-SPAM act.

Validate sign up forms using our free validation tools.

Monitor your IP reputation using tools like SenderScore.org.

Read our Email Best Practices docs.

Mailgun has thresholds in place that if exceeded will result in a domain being temporarily disabled. These limits are in place to protect your email reputation in case your system is compromised by a spammer or someone in your organization makes a large mistake.

If you do not have a good reputation tied to your domain and IP address, your email will not reach your recipients inboxes.

The number one reason we see people get blocked is that they have a bad mailing list. Most of these lists have bad email addresses and include spam traps. ESPs are good at recognizing bad mailing lists. Best practices for lowering bounce rates:

Clean your mailing list of invalid email addresses.

Only send emails to recipients that have signed up to receive them.

Verify the email address is correct with a confirmation email (aka, confirmed opt-in ).

We recommend using our email validator at the point of signup to reduce invalid email addresses.

Dont purchase your list or scrape websites for emails.

If your domain does get disabled, contact support after you have made the recommended changes above and wewill re-enable your domain.

The answer to this depends on several factors; having a dedicated IP can be the perfect (or even necessary) setup for your account. Shared IPs are essentially like large public highways; most of the time, you canget everywhere you need to go, quickly, just fine. Sometimes though, the actions of others slow down or even halt your progress.Contrast this with the dedicated IP; a nice private sending highway, just for you, to move about and fly through freely. However - a dedicated IP isn't a magic solution to all the problems you might encounter in sending email; if your account doesn't meet certain criteria, a dedicated IP won't be a great solution - just more on your invoice. Exactly what we don't want!

This being understood, here is some general guidance on the subject:

Usea dedicated IP if:

You are consistentlysending at least than 5,000 messages per month. Since it's just you on the dedicated IP, there's a certain amount of sending necessary to establish and sustain a solid reputation. Otherwise, sending too few messages can be just as damaging as sending too many messages - ESPs treat the IP with suspicion. Consistency is key - this is all about establishing a trust relationship with the ESPs to whom you send.

Use a shared IPif:

You are sending less than 5,000 messages per month, or if your sending is volatile, with large spikes and dips in volume. ESPs may assume those large spikes fit spam patterns, and treat your sending with suspicion. Sending too few messages can be as bad as sending too many for an IP's reputation.

Usea pool of dedicated IPsif:

You are ahigh volume sender*, asESPs limit the total volume per IP per hour.

To separate your bulk and transactional mail completely (or to separate other kinds of sending from one another). To do this effectively, you'd be using a distinct dedicated IP per domain, so that you don't have any crossover between domains, affecting one another.

Additional information about dedicated IP addresses and sending volume can be found in the Email Best Practices section of our documentation.

Don't forget - these are general guidelines based on what we've seen demonstrated to work best for the majority of cases. Understanding each use case works slightly differently, if you believe a dedicated IP is the best option for your account, but don't happen to fit these exact numbers, contact our Support team via the Supportoption in your Mailgun control panel. We'll be happy to review your specific case to advise on the best course of action to optimize your account's IP arrangement.If your account does happen to match these guidelines and you'd like to add a dedicated IP, you'll just use that sameSupportoption in your Mailgun control panel - our team is standing by to ensure we're getting your account setup with its best arrangement.

* High volume senders are those looking to send several million emails per month

There are many factors that can affect the speed of delivery.

Your established reputation for the domain and IPs on your account.

The total number of IPs allocated to your account.

The content quality for the emails being sent.

For newly allocated IPs, Mailgun protects and improves the reputation by gradually increasing sending rates. This means, as time passes, with high quality traffic, being sent from your IPs, your sending rates will increase automatically.

If youre constantly seeing slow delivery, please contact us. Well evaluate your account configuration to ensure it is configured for handling the volume you require.

Domains are obviously fundamental to begin using your Mailgun account; it's where you're sending from! Aside from the limited testing options provided by an account's sandbox domain, a custom or personal domain is required to send emails through our platform, build a reputation, and establish a professional identity with your emails. Check out our article on how to choose a domain if you do not already have a domain.

Adding A Domain

Inside theMailgun Control Panel (options displayed down the left-hand side on a dark column), use the following instructions:

Click onSendingon the left-hand side of yourthe Mailgun dashboard.

Click the greenAdd New Domainbutton.

Enter your Domain Nameand choose your additional options.

The region your domain will reside: US or EU.

Create DKIM Authority - you would generally leave this checked by default.

DKIM Length - a longer DKIM key will make spoofing your emails by malicious spammer more difficult. 1024-bit is selected by default, but 2048-bit can be used as well.Note: Some DNS providers may have an issue with a 2048-bit DKIM keys, as they produce a string longer than 255 characters (exceeding the maximum character limit for a DNS entry).

Once your options are set, clickAdd Domainto save your new domain.

The next page will provide you with the DNS records required for your domain to be verified with Mailgun. This information is also available in the Domains section of the control panel by clicking on a specific domain name.

If you need assistancegetting your domain verified, check out this help center article.

If you would like to add a domain using the domains API, you can find more information inour documentation.

Deleting A Domain

What if you no longer use a domain or if there is a typo in the domain name? We'll show you below how you can eliminate the domain from the account.

Inside theMailgun Control Panel (options displayed down the left-hand side on a dark column), use the following instructions:

Click onSendingon the left-hand side of your Mailgun dashboard.

On the resulting page, click the domain you wish to delete.

Click on Domain Settings on the left-hand side of your Mailgun dashboard.

Towards the bottom of the resulting page, there will be a button that allows you to delete the domain from the account.

If you would like to delete a domain using the domains API, you can find more information inour documentation.

If any questions arise, just reach out to our Support team via the Support option in your Mailgun control panel!

Verifying your domain is an essential step to start sending email through Mailgun. We ask all of our users to verify ownership to enable open and click tracking, mitigate spam, and ensure that nobody can send from your domain besides you and your organization.

This step-by-step guide will walk you through how to add and verify a domain in Mailgun. For this example, Cloudflare will be used as the website hosting provider. However, it should be noted that these steps are the same for other hosting providers as well.

If your domain is already hosted somewhere (like Cloudflare ), youll need to login to your provider to change DNS records. If your domainisn'thosted anywhere yet, you can setup a free account at Cloudflare and follow along this guide.

Step 1: Add your domain to Mailgun

Ifyou'vealready added your domain, skip to step 2

Before you can verify a domain, it needs to be added to Mailgun.

Login to your Mailgun account, click Domains on the left hand side, and then click the green Add New Domain button.

Submit a ticket

Enter your domain name into the box. We recommend using a subdomain for better email deliverability. In this example, we used mail.yourdomain.com. If you want to use just your domain name, thats fine too.

After you click Add Domain, youll be taken to a screen asking you to add DNS records to your domain. Leave this screen open for the next step.

Step 2: Add DNS Records to Hosting Provider

Login to your hosting provider and navigate to the DNS section. This area is called DNS at Cloudflare, but weve seen it called Networking in Digital Ocean and Zone Editor in cPanel.

Next, youll be asked what type of DNS records you want to add. Well go through each one individually.

TXT Records

The first records Mailgun asks you to add are TXT records. We will add two separate TXT records, one for SPF and one for DKIM. These are required to send and receive email with Mailgun.

If youre using a subdomain, add a new TXT record with mail.yourdomain.com as the hostname (with certain providers, you may just have to enter the subdomain, which would just be mail in this case) and the appropriate value Mailgun provides. You can leave TTL as the default option.

If youre not using a subdomain, most providers will accept @ as the hostname when creating DNS records for the root domain. Heres an example:

Clicking Add Record will add your first DNS entry for your domain!

Add another TXT record for mx._domainkey.mail.yourdomain.com. Cloudflare only shows the subdomain, so your result will look like this:

MX Records

Next, you need to add MX records. Mailgun requires you to add two separate MX records.

You will add the MX records the same way you did with the TXT records. The hostname in this case is mail.yourdomain.com Youll also be asked for priority, which should be 10.

CNAME Record

Lastly, you will need to add a CNAME record. The CNAME Record is what enables Open and Click tracking. This is highly recommended to reap the full benefit of Mailgun and gain insights into your email performance.

Add the CNAME the same way as the others. The hostname here is email.mail.yourdomain.com

Step 3: Wait (up to 24 hours)

It can take up to 24 hours for DNS changes to propagate across the internet. In our experience, it usually happens faster than that, butdon'tget discouraged if it doesnt happen immediately. If everything is setup right youll receive an email from Mailgun like this:

If youre impatient like us, you can also use the Check DNS Records Now button on the DNS Settings page.

Having trouble? Our support team is open 24/7. from inside the Mailgun control panel for a faster response.

Why Do I Need to Verify My Domain?

Mailgun requires domain verification for two primary reasons. First, it confirms that you are the owner of the domain, preventing unauthorized senders from using your domain in our platform. Second, the SPF and DKIM records authorize our SMTP servers to send on behalf of your domain. This serves to significantly improve your deliverability - our specialty!

DNS records can be a bit tricky, but if you know a few tips, you can greatly enhance your success with the process. Lets take a look at some common issues seen when attempting to verify your domain.

I Created My Records, but Mailgun Does Not See Them.

You always want to double-check any changes you make to your DNS configuration via both a local and a public query. Local queries can be performed using built-in utilities like dig (Linux/Unix) and nslookup (Windows).

To verify via a dig command,the syntax is: dig -t <record type> <hostname>

dig -t TXT domain.tld ; <<>> DiG 9.8.3-P1 <<>> -t TXT domain.tld;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64695;; QUESTION SECTION:;domain.tld. IN TXT;; ANSWER SECTION:domain.tld. 600 IN TXT "v=spf1 include:mailgun.org ~all"

To verify via nslookup,the syntax is: nslookup -q=<record type> <hostname>

nslookup -q=TXT domain.tldServer: 1.1.1.1Address: 1.1.1.1#53Non-authoritative answer:domain.tld text = "v=spf1 include:mailgun.org ~all"

In some cases, there might be a local DNS server within your network that will take precedence over public queries. Even if youdon'thave a local DNS server, we recommend performing a secondary public query for your domain. One great tool is Whats My DNS - https://www.whatsmydns.net/. Whats My DNS will query multiple servers around the globe to best gauge the propagation of your changes.

To use, just enter your hostname and select the record type from the options present in the dropdown.

If the correct value is returned - congratulations! The record was successfully created.

If you do not see the correct value (or see all red Xs) - something'snot quite right yet. Make sure to double-check your configuration and correct your DNS setup as needed.

Note: Some DNS provider's panels will automatically append the root domain name following whatever's placed in the hostname value; for instance, if your domain is mail.example.com, you might only need "mail" in the hostname field, or you could be creating a record for mail.example.com.example.com by accident. To help ensure productive use of your time, reach out to your DNS provider to find out how their panel operates.

The DKIM Record Is Verified, but the SPF Is Not

It takes two TXT records to verify your domain; SPF and DKIM. If everything looks good with your DKIM record, but not with your SPF, here are a few elements to check:

There can only be 1 SPF record per hostname. If your hostname has more than 1 SPF record, the records will need to be merged into a single value.

dig -t TXT domain.tld "v=spf1 include:mailgun.org ~all""v=spf1 ip4:1.2.3.4 include:smtp.domain.tld ~all"

In this case, the issue is occurring due to the separation of the values into two separate entries. The fix is simple - just combine them. You can place the Mailgun include directive (include:mailgun.org) anywhere after v=spf1 and before ~all. The new value would be:

v=spf1 ip4:1.2.3.4 include:smtp.domain.tld include:mailgun.org ~all

Note: Make sure that your SPF record doesn't exceed 10 lookups, or you'll run into issues.

If the hostname has a CNAME in addition to any other record type (i.e. TXT, A, etc), the CNAME will take precedence.

dig domain.tlddomain.tld. 300 IN CNAME mailgun.orgdomain.tld. 300 IN TXT "v=spf1 include:mailgun.org ~all"

To resolve this and verify the TXT, the CNAME would need to be removed from the hostname. Alternatively, another sending subdomain would need to be used with the Mailgun account, such as (for this example) mg.domain.tld.

The Records Are Resolving, but Mailgun Still Says That the Domain Is Unverified

Depending on the DNS hosting provider, records can take up to 24-48 hours to fully propagate. A manual verification can be attempted if 24 hours have already passed and the records are confirmed correct via both local and public queries.

To perform a manual verification and update the DNS records cache, log into your Mailgun control panel. Inside theMailgun Control Panel(options displayed down the left-hand side on a dark column), use the following instructions:

Click Messages.

Select your specificdomain.

Click Settings.

Select DNS Records.

Click the greenCheck DNS Records Nowbutton.

Other DNS Records - Optional

While the two TXT records (SPF and DKIM) are all that's required to send messages via Mailgun, you do also have the option to add MX and CNAME records, if you choose. The process for adding these optional records is exactly the same as adding the required TXT records.MX records are really only needed if you're looking to receive incoming mail for the exact domain or domains you have verified in your Mailgun account; keep in mind - you don't want to point your domain's MX records to Mailgun if you already have incoming mail setup elsewhere. If you do, adding Mailgun MX records will break this configuration, and you won't receive your mail as you have previously.Note: You only ever want to have one source specified for your MX records, otherwise servers get confused. Bad things happen when servers get confused.

A CNAME record is needed only if you're looking to enable our tracking features, keeping detailed records of Clicks, Opens, and/or Unsubscribes.

If you are still experiencing any issues after the domain's DNS records are publicly resolving, just reach out to our Support team via the Support option in your Mailgun control panel!

"Poor Mailing List" means that too many of the messages you have submitted were rejected/bounced because the address you were sending to was invalid.

In an effort to protect your domain's reputation, and the reputation of our IP's when the percentage of bounced messages gets too high, your domain is automatically disabled.

Here are a few things you will need to do before we can enable your account:

Clean your mailing list andremoveany addresses that are bouncing from that list.

Create a support ticket andprovide us with details about how you obtain the email addresses to which you are sending. If there is a signup form or web portal, please provide the link for review.

In your support ticket please provide answers to the following questions as well:

What types of emails are you sending? (Please explain the nature of your business and why these emails are related).

Are all of your email addresses double-opt in? (This means that the user has requested your emails through sign-up and then confirmed via email that they want to receive your communication).

You can find some additional information in our email best practices andin our article on how to lower your bounce rate.

If you have any additional questions, please include them in your support ticket and we'd be happy to address those in our response.

To help protect our customers against spam, we have automated systems in place that flag accounts that contain elements that could be considered suspicious.

Most of the time this works pretty well; sometimes though, what the system deems as potentially suspicious is perfectly innocent, and so we end up flagging a genuine, decent account. There are a number of factors contributing to this; as is so often the case in email, there are many variables. So - if you see this message, not to worry; it's not a comment on you or your business. It might not even be something directly related to you; for example, it could be you're happening to use an IP that was flagged as suspicious in the past. These things happen - we're just making sure everything's alright.

If you see the "Business Verification" message, we ask that you contact our Support team via the Support option in your Mailgun control panel. To make the process as quick and painless as possible, because we're really just looking to verify you're a quality sender, please provide the following information, so that we can best understand your needs:

What types of emails will you be sending - transactional or marketing? Please tell us briefly about how your business uses email.

Where do you source your database/list of email addresses? Also, please provide any available URL(s) to the website(s) you'll be using with Mailgun.

Are all of your email addresses double-opt-in? (This means that the user has requested your emails through sign-up and then confirmed via email that they want to receive your communication).

What is your expected monthly volume of messages?

Have you read our Email Best Practices document?

Please provide a link to your Privacy Policy, Terms of Service, and Sign-up link (if applicable).

Please provide a sample email you would typically send to your users.

As mentioned, we're doing this not to hassle you, but rather to help protect all the users on our system. Business Verification is in place so that we can make sure to give quality users a thumbs-up, and quickly prevent those not practicing good habits from getting in and ruining everyone else's success.

If any questions arise, just reach out to our Support team via the Support option in your Mailgun control panel!

Mailgun has thresholds in place that if exceeded will result in a domain being temporarily disabled. These limits are in place to protect your email reputation in case your system is compromised by a spammer or someone in your organization makes a large mistake.

If you do not have a good reputation tied to your domain and IP address, your email will not reach your recipients inboxes.

The number one reason we see people get blocked is because they have a bad mailing list. Most of these lists have bad email addresses and include spam traps. ESPs are good at recognizing bad mailing lists.

You can check your logs to see emails that are bouncing and check your suppression list for emails that we have stopped sending to as a result of bounces.

Best practices for lowering bounce rates include:

If you think your application has been compromised, change your SMTP credentials or API key through the Mailgun control panel.

Clean your mailing list of invalid email addresses.

Only send emails to recipients that have signed up to receive them.

Verify the email address is correct with a confirmation email (aka, confirmed opt-in ).

We recommend using our email validation service at the point of signup to reduce invalid email addresses.

Dont purchase your list or scrape websites for emails.

If your domain does get disabled, contact support after you have made the recommended changes above so we can re-enable your domain.

Mailgun Templates allow you to create, store and edit your HTML templates on Mailgun's platform so that you can simply reference the template during your sends using the same sending API!

Mailgun Templates can be found in our new user interface by navigating to one of your domains and selecting Templates from the available tab options:

https://documentation.mailgun.com/en/latest/api-sending.html#sending

From here, you would click on the Create Message Template button and choose from a set of default templates to get started!

Mailgun Templates allows you to design your own or build off of a pre-existing template we have available to then save and send with the API.

Mailgun Templates are great for either transactional messages or marketing messages! For instance, transactional messages such as Email Receipts for Orders or marketing messages such as Bulk Messages or Newsletters.

For more information regarding how to use Mailgun Templates with our API, please be sure to check out our updated docs here:

https://documentation.mailgun.com/en/latest/user_manual.html#templating

All is going well with your regular sending when an odd message appears:"Relaying Denied." What does this mean, exactly? Essentially, it's just what the message indicates; the relaying of this email was not allowed. You could call this the "Do not pass Go, do not collect $200" of email errors.

While this is usually an authentication issue, there are 3 different common scenarios that provide some context for the bounce. The bounce message can be:

Coming from Mailgun for outgoing emails

Coming from Mailgun for incoming emails

Coming from the external recipient host for outgoing emails.

So - a key element of resolving this error is finding just which instance you're experiencing.

Response from Mailgun (Outgoing)

In this scenario, you've attempted to send an email with Mailgun via SMTP, but received the Relaying Denied response during the SMTP session with Mailgun.This indicates the SMTP session was not authenticated. Specifically, this happens when the RCPT TO command is used for an external email address before the SMTP session was authenticated.

The solution to this is to ensure your SMTP application is properly configured to authenticate, using your Mailgun SMTP credentials. We might not be able to provide exact instructions for your SMTP application, but you can find the required SMTP credentials in the domain settings page in your Mailgun control panel:

Inside theMailgun Control Panel(options displayed down the left-hand side on a dark column), use the following instructions:

ClickSending

Select yourdomain's name

ClickDomain Settings

SelectSMTP credentials

Note: All outgoing emails are required to be authenticated via SMTP or the API.

Response from Mailgun (Incoming)

In this scenario, you or a colleague has tried to send an email to an email address for which you use Mailgun Routes (how we process incoming mail). In other words - the recipient domain's MX records point to Mailgun.

In this context, the sending application will establish an SMTP session to Mailgun's MX server and issue a RCPT TO command for the recipient. If your Mailgun account does not have a route or is not properly configured to catch this recipient address, Mailgun will return a Relaying Denied error.

You'll need to check the details of your Routesand ensure your domain is properly configured to route the recipient address. We have a help article that will help you set up your Routes and ensure they are configured properly. You can check it out by clicking here.

Response from Recipient Host

In this scenario, you've successfully submitted an outgoing email to Mailgun. Mailgun then attempts to deliver the email to the recipient host, but it generates a failed event with the Relay Denied message.

This bounce message is being returned by the external recipient host and not Mailgun in this scenario. It typically means the email address is invalid. The recommended action is to double check the recipient email address is correct.

If you have any questions, please open reach out to our Support team via the Support option in your Mailgun control panel- our team will be happy to assist!

Authentication is required any time you wish to relay messages through our platform. When using our API, you need to use one of your account's API keys (either the Private API Key or the Public Validation Key).

For our SMTP server, you need to use your domain's SMTP credentials.

Note:If the API keys are not visible within your Control Panel, verify your permissions with your account's Admin user.

API Keys

Inside theMailgun Control Panel(options displayed down the left-hand side on a dark column), the API keys appear on only one page. To view the API keys, use the following instructions:

Click onSettingson the left-hand side of yourthe Mailgun dashboard.

Select Security & Usersfrom the menu below on the left-hand side.

Click on the API security tab.

On the following page, under theAPI Keyssection, you'll see both your Private and Public API keys.

Click on the eye icon to make the full API key visible.

SMTP Credentials

Your SMTP credentials are different for each domainyou add. You can find your default credentials, and add more, by clicking through to your domain settings.

Inside theMailgun Control Panel(options displayed down the left-hand side on a dark column), the SMTP Credentials are not visible and can only be reset. To update your SMTP credentials, use the following instructions:

Click onSendingon the left-hand side of yourthe Mailgun dashboard.

Select the specific domain.

On the following page click on Domain Settings,thenclickSMTP credentials.

To update the password clickReset Password.

Confirm your password reset by clickingReset Passwordin the pop-up.

Your SMTP credential's new password will be displayed on the top-right corner within a green pop-up. Save this password by double-clicking on the string and copy+pasting into a safe location, as it will not be revealed again.

What Ports Does Mailgun Support?

Our servers listen on ports 25, 465 (SSL/TLS), 587 (STARTTLS), and 2525.

A few things to note when selecting a port:

Some ISPs block or throttle SMTP port 25. We recommend using port 587 instead.

Google Compute Engine allows port 2525 for SMTP submission.

Mailgun IPs change frequently, we do not recommend setting up firewall restrictions against our IP addresses.

See our SMTP documentation in the users manual to learn how to configure the most popular SMTP software and email clients to work with Mailgun.

For a more detailed explanation on ports check out our blog post.

If any questions arise, just reach out to our Support team via the Support tab in your Mailgun control panel!

Choosing the right domain name might seem obvious - your company is X, so why shouldn't your domain beXas well?Well, depending on how you're looking to use Mailgun, implementing just the right level of nuance can make a significant difference on the effectiveness of your configuration, as well as improve your deliverability.If your companys primary domain is mycompany.com, we recommend the following domain names for Mailgun:

mycompany.com -unless youre already using this name for your corporate email (e.g. with Gmail or another provider).

mg.mycompany.com, or mail.mycompany.com

mycompany.net or mycompany.org

We requireyou to configuretwo TXT records (SPF and DKIM) at your DNS provider so we can verify you own this domain. We provide you with those records and instructions in your control panel. More information on getting your domain verification taken care of here.

Sometimes, it is a good idea to separate the domains for the type of messages you are sending. For example, some companies will use a different domain or subdomains for bulk marketing mailings, versus those domains used fortransactional or corporate mail. This is done in order to keep the reputations separate. Using this method, your marketing mail's large sudden sends for campaigns don't halt the gradual, consistent flow of your transactional or corporate mail.

You could segment domains per mailing type like this:

mail1.mycompany.com for transactional emails

mail2.mycompany.com for marketing emails

Simple, yes? Finally, if you want multiple addresses and you want to direct certain emails to certain IP addresses, you will need to have a unique domain or subdomain for each IP address. In this situation, contact our Support team via the Support option in your Mailgun control panelto discuss your infrastructure.

Should questions about other matters arise, just use the same method toreach out to our Support team to help get your problem solved!

With both Free and Concept plans, you receive 10,000 free messages per month. However, there are some limitations on the Free plan:

There is a limit of300messages per day on the included sandbox domain

Data retention for Logs and the Events API is 1day

You cannot create custom domains

Use of Authorized Recipients is required; there is a maximum of 5 Authorized Recipients

However, if you place your payment information on file, you're upgraded to the Concept plan (so it's essentially the Free plan, with credit card information present). With the Concept plan comes the following benefits:

There is no limit on the number of emails sent or received

You get10,000 free messages a month. If you send over this amount, you're only charged per the overage, at a rate of $0.50/1000 messages

Data retention for Logs and the Events API is 5 days

You can create up to 1,000 domains

Use of Authorized Recipients is not required to send with custom domains; you may send to whomever you like!

If these limits are not enough for your needs, take a look at our other plans via ourpricing page: https://www.mailgun.com/pricing/. You'll find a full list of features and attributes to help inform your decision-making process.If you don't find what you're looking for there,let's consider a custom contract!Our Sales representatives are here to find the best possible fit for your needs; you can reach them at [email protected].

Need help upgrading your account? Check out this article.

If any questions arise, just reach out to our Support team via the Support tab in your Mailgun control panel!