Anti-Spam Protection FAQ
Applies to: Exchange Online Protection, Exchange Online
Topic Last Modified: 2013-04-15
This section provides frequently asked questions and answers about anti-spam protection. Answers are applicable for Microsoft Exchange Online and Exchange Online Protection customers.
Q. By default, what happens to a spam-detected message?
A. The majority of spam is deleted via connection filtering. By default, content-filtered spam is sent to the recipient’s Junk Email folder. You can change this action. For example, you can choose to send spam messages to the quarantine instead by configuring the content filter policy.
|For Exchange Online Protection customers: In order to ensure that the Move message to Junk Email folder action will take effect, you must configure two Exchange Transport rules on your on-premises servers to detect spam headers added by the hosted spam filtering. For details, see Ensure that Spam is Routed to Each User's Junk Email Folder.|
Q. Do I need to configure the service to provide anti-spam protection?
A. After you sign up for the service and add your domain, spam filtering is automatically enabled company-wide through the default anti-spam policies. The default policies are tuned to protect you without needing any additional configuration. However, as an administrator, you can edit the default anti-spam policies so that they are tailored to best meet the needs of your organization. For more about configuring your anti-spam policies, see the following topics:
Q. Is bulk email filtering automatically enabled?
A. By default, the Block all bulk email messages advanced spam filtering option is enabled for new customers. For migrated customers, this setting will match your FOPE configuration.
Q. Does the service block a URL in an email message because it was "known"? Or will it also know when a message contains a URL that appears as www.treyresearch.net but is really malicious and will direct you to a different address?
A. The URL filter only extracts (known) malicious URLs.
Q. How can customers using the service send false negatives (spam) and false positives to Microsoft?
A. False negatives: A false negative is a spam message that passes through filtering to a recipient. You can send via the Junk Email Reporting Add-in for Microsoft Office Outlook or by emailing to email@example.com in the manner described in Submitting Spam Messages to Microsoft for Analysis.
False positives: A false positive is a legitimate message that is filtered as spam. You can email to firstname.lastname@example.org in the manner described in Submitting Spam Messages to Microsoft for Analysis. Spam quarantined messages can also be released and submitted by administrators from the Exchange admin center; for more information about how to do this, see Release a Quarantined Message and Optionally Report it as a False Positive.
Q. Can I get spam reports?
A. Yes, you can obtain reports in the Office 365 portal or by downloading an Excel reporting workbook. For more information about reporting, see the following links:
Exchange Online customers: Monitoring, Reporting, and Message Tracing in Exchange Online
Exchange Online Protection customers: Reporting and Message Trace in Exchange Online Protection
Q. Someone sent me a message and I can’t find it. I suspect that it may have been detected as spam. Is there a tool that I can use to find out?
A. Yes, the message trace tool enables you to follow email messages as they pass through the service, in order to find out what happened to them. For more information about how to use the message trace tool to find out why a message was marked as spam, see Was a message marked as spam?
Q. Will the service throttle (rate limit) my mail if my users send outbound spam?
A. No. If an outbound message is determined to be spam, it is routed through the high risk delivery pool, which reduces the probability of the normal outbound-IP pool being added to a block list. If a user continues to send outbound spam through the service, they will be blocked from sending messages.
You can send a notification to a specified email address when a sender is blocked sending outbound spam. For more information about this setting, and how to contact technical support to get the mailbox re-enabled, see Configure the Outbound Spam Policy.
Q. What are a set of best outbound mailing practices that will ensure that my mail is delivered?
A. The guidelines presented below are best practices for sending outbound email messages.
- The sending domain of the email should resolve in DNS.
For example, if the sender is email@example.com, the domain example.com resolves to the IP address 22.214.171.124. If a sending domain has no A-record and no MX record in DNS, the service will route the message through its high risk delivery pool regardless of whether or not the content of the message is spam. For more information about the high risk delivery pool, see Understanding the High Risk Delivery Pool for Outbound Messages.
- The sending IP address of the outbound mail server should have a reverse DNS (PTR) entry.
For example, if sending from the IP address 126.96.36.199, the reverse DNS entry for this IP is 43-10.any.icann.org.
- The HELO/EHLO and MAIL FROM commands should be consistent and be present in the form of a domain name rather than an IP address.
The HELO/EHLO command should be configured to match the reverse DNS of the sending IP address so that the domain remains the same across the various parts of the message headers.
- Ensure that proper SPF records are set up in DNS.
SPF records are a mechanism for validating that mail sent from a domain really is coming from that domain and is not spoofed. For more information about SPF records, see the following links:
Customize an SPF Record to Validate Outbound Email Sent from Your Domain
Create DNS records for Office 365
Microsoft’s Sender ID wizard
- Signing email with DKIM, sign with relaxed canonicalization.
If a sender wants to sign their messages using Domain Keys Identified Mail (DKIM) and they want to send outbound mail through the service, they should sign using the relaxed header canonicalization algorithm. Signing with strict header canonicalization may invalidate the signature when it passes through the service.
- Domain owners should have accurate information in the WHOIS database.
This identifies the owners of the domain and how to contact them by entering the stable parent company, point of contact, and name servers.
- For bulk mailers, the From: name should reflect who is sending the message, while the subject line of the message should be a brief summary on what the message is about.
The message body should have a clear indication of the offering, service, or product. For example, if a sender is sending out a bulk mailing for the Contoso company, the following is what the email From and Subject should resemble:
Subject: New updated catalog for the Christmas season!
The following is an example of what not to do because it is not descriptive:
- If sending a bulk mailing to many recipients and the message is in newsletter format, there should be a way of unsubscribing at the bottom of the message.
The unsubscribe option should resemble the following:
- If sending bulk email, list acquisition should be performed using double opt-in. If you are a bulk mailer, double opt-in is an industry best practice.
Double opt-in is the practice of requiring a user to take two actions to sign up for marketing mail:
Once when the user clicks on a previously unchecked check box where they opt-in to receive further offers or email messages from the marketer.
A second time when the marketer sends a confirmation email to the user’s provided email address asking them to click on a time-sensitive link that will complete their confirmation.
- Once when the user clicks on a previously unchecked check box where they opt-in to receive further offers or email messages from the marketer.
- Bulk senders should create transparent content for which they can be held accountable:
Verbiage requesting that recipients add the sender to the address book should clearly state that such action is not a guarantee of delivery.
When constructing redirects in the body of the message, use a consistent link style.
Don’t send large images or attachments, or messages that are solely composed of an image.
When employing tracking pixels (web bugs or beacons), clearly state their presence in your public privacy or P3P settings.
- Verbiage requesting that recipients add the sender to the address book should clearly state that such action is not a guarantee of delivery.
- Format outbound delivery status notifications.
When generating delivery status notification messages, senders should follow the format of a bounce as specified in RFC 3464.
- Remove bounced email addresses for non-existent users.
If you receive an NDR indicating that an email address is no longer in use, remove the non-existent email alias from your list. Email addresses change over time, and people sometimes discard them.
- Use Hotmail’s Smart Network Data Services (SNDS) program.
Hotmail uses a program called Smart Network Data Services that allows senders to check complaints submitted by end users. The SNDS is the primary portal for troubleshooting delivery problems to Hotmail.