Have you set up an email trigger, and you're sure you've followed all the instructions but when you send the email to the right address...nothing happens? Or maybe you see a bounce indicating the message was rejected due to something called a "Relay access denied" error?
The issue
There are a few common reasons why an email trigger might not initiate a flow in xMatters, even when the address looks correct:
Your SMTP server is configured to allow CNAME expansion for email addresses, and it is modifying the trigger address in transit.
The email never actually reaches xMatters because an upstream mail system (for example, an internal SMTP relay or third-party provider) is down.
The source system is sending to a different or modified address than the one configured for the email trigger.
To use email to trigger a flow in xMatters, you must send an email to an address matching the following format:
<recipient>@<triggerID>.<company>.xmatters.com
When CNAME expansion is enabled, an email sent to mmcbride@traveladvisory.example.xmatters.com might be changed during transit through your email server to something more like mmcbride@us1-west-1.mail_traveladvisory.example.xmatters.com, which xMatters does not recognize as a valid trigger address.
If your monitoring or reporting tool sends email via an internal SMTP relay and that relay is unavailable, xMatters will not receive the alert email and cannot initiate notifications. Similarly, systems that send via third-party SMTP services may stop sending to your trigger address if a previous message bounced; in that case, xMatters will show no inbound activity because the sender is no longer attempting delivery.
The solution
To resolve issues where the address is being rewritten, you need to work with your IT team to disable the CNAME expansion setting on your SMTP email server.
As an example, here's a description of the CNAME expansion setting on a Sendmail email server (from the Sendmail documentation):
confDONT_EXPAND_CNAMES DontExpandCnames
[False] If set, $[ ... $] lookups that
do DNS based lookups do not expand
CNAME records. This currently violates
the published standards, but the IETF
seems to be moving toward legalizing
this. For example, if "FTP.Foo.ORG"
is a CNAME for "Cruft.Foo.ORG", then
with this option set a lookup of
"FTP" will return "FTP.Foo.ORG"; if
clear it returns "Cruft.FOO.ORG". N.B.
you may not see any effect until your
downstream neighbors stop doing CNAME
lookups as well.When troubleshooting cases where no incident or alert is created and there is no obvious SMTP error:
Confirm that the source system is sending directly to the trigger address (for example, database@incident.<your-domain>.xmatters.com) and not just forwarding from an internal user.
Check xMatters inbound email activity for that trigger to see whether any delivery attempts are recorded around the time of your test.
Ask the sending system or SMTP provider (for example, SendGrid) for their send and delivery logs, including status (accepted, bounced, suppressed) and timestamps for messages to the trigger address.
If a verification or test email to the trigger address was not received, collect the approximate send time and the sending domain so xMatters Support can investigate.
More information
xMatters does not use CNAMEs for their mail servers. Instead, MX records go to load balancers, and the request uses the load balancer address instead of the instance hostname which is required to properly source the initiation.
For a more thorough explanation of CNAME expansion, check out these SMTP articles from IETF.org:
(To save you a little time, the money quote appears to be this one: The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found instead, the resulting name is processed as if it were the initial name.)
For more information on using email to integrate with xMatters, see the email trigger description in the online help.
Comments
0 commentsPlease sign in to leave a comment.