SPF records (EMail)

 

Sender Policy Framework (SPF) is an email standard that pioneered the concept of domain-based email authentication. Below, we’ll walk you through everything you need to know about SPF, including what it is, how it works, limitations, and solutions.

What is SPF?

SPF prevents spoofing by enabling domain owners to allowlist IP addresses of servers that are authorized to send email on the domain’s behalf.

If a mail server with an IP address not on the list tries to send an email using that domain, it won’t pass SPF authentication.

How SPF email records work

Here’s a quick overview of how SPF works:

1. Publish SPF record: Domain owners publish SPF records to the Domain Name System (DNS) that spell out the rule sets for their domains. An SPF record is plain text, and it can be as simple as a single line listing the IP addresses allowed to send an email on the domain’s behalf.
2. Perform DNS lookup: When an email server receives an incoming email, it performs DNS lookups to retrieve the SPF record for a domain and examines the domain shown in the message’s Return-Path.
3. Process SPF record: It will then process that SPF record to attempt to find the IP address of the sending server in the SPF record. This typically requires further DNS lookups to process parts of the SPF record linked in “include” statements. Notice the “include” statements in the above SPF record
4. Pass or fail test: If there’s a match, the email passes the test and, in most cases, is delivered to the user’s inbox. If there is no match, the receiving server will treat the email as having failed SPF verification and will typically reject the message or add a flag to it, marking it as suspicious.

SPF risks and limitations

While SPF is better than nothing, it’s not a complete solution to protect your sending domains. Here are a few of the risks and limitations of SPF:

1. Identifying and originating IP addresses for SPF records
2. SPF 10 DNS lookup limit 
3. SPF is spoofable
4. Email SPF doesn’t survive email forwarding 

1. Identifying originating IP addresses for SPF records

SPF only lets you know that a message came from an approved IP address. But an approved IP address isn’t that easy to find. 

Shared systems like cloud platforms can host multiple cloud services that are dynamically assigned IP addresses at runtime. If the IP address identifies a service that you authorize, such as MailChimp, then anyone using the same IP address on that system could send messages that authorize with your SPF record.

2. SPF 10 DNS lookup limit 

The SPF standard limits the number of DNS lookups that mail servers will do when evaluating an SPF record. Before cloud services became common, 10 DNS queries were sufficient because most email messages were sent from applications hosted by the domain owner.

For modern cloud services, 10 lookups can go quickly, particularly because one lookup might contain other nested “include” statements requiring further DNS queries. When this article was published, G Suite’s “include _spf.google.com” actually comprised four different lookups because the SPF record at _spf.google.com contains three more lookups of its own.

Many folks implementing email authentication realize they must include all their cloud-sending services. To include them all means the SPF record exceeds the 10 DNS lookup limit. To mitigate the limitations of 10 domain lookups, they “flatten” the SPF record by pulling all the IP addresses of approved sending services forward into the primary SPF record.

Fluctuations in the IP addresses used by a cloud platform or sending service will require constant updates to the SPF record to prevent good email from being blocked. Some vendors attempt to cover any possible changes to IP address blocks used by cloud providers by specifying wide ranges in the SPF record—in tens of thousands to millions of IP addresses. Overly permissive IP blocks can allow fraudulent senders to send email on behalf of your domain, defeating the purpose of DMARC enforcement.

3. SPF is spoofable

SPF uses the domain shown in a message’s Return-Path field for authentication, not the “From:” address that humans can read. This creates a few issues:

1. The “From:” address can still be spoofed.
2. The Return-Path indicates where bounce messages should go, so the “From:” and Return-Path domains may differ. Most mail clients do not display the Return-Path address by default. For example, if you’re sending mail through a mailing list, the “From:” field might show your address, while the “Return-Path:” field shows the address of the email list.
3. Phishers can use the general invisibility of “Return-Path:” when setting up their domains with their own SPF records. Then, they can send phishing emails with a company’s domain showing in the “From:” field but the phisher’s domain in Return-Path. Such messages are fake, but they will pass SPF authentication.

4. Email SPF doesn’t survive email forwarding 

SPF does not inherently support email forwarding. Any SPF records from senders trying to reach you through a forwarding address won’t validate because, to the receiving server, it looks like the message is coming from the forwarding server—not the source-identifying originating IP addresses.

SPF only lets you know that a message came from an approved IP address. This doesn’t always represent a one-to-one relationship. 

Shared systems like cloud platforms DMARCcan host multiple cloud services that are dynamically assigned IP addresses at runtime. Some could use the same IP address. Or if the IP identifies a service that you authorize, say MailChimp, then anyone using the same IP address on that system could send messages that authorize with your SPF record.

Get complete DMARC, DKIM, and SPF protection

SPF is an essential part of email authentication but wasn’t designed for the cloud era. On its own, SPF will not authenticate email. However, in the absence of a DMARC record, how receiving servers handle a message that fails SPF is entirely up to them.

Another most important exchange server term is DMARC record.

DMARC (Emails) in simple terms

 

Email authentication technologies SPF and DKIM were developed over a decade ago in order to provide greater assurance on the identity of the sender of a message. Adoption of these technologies has steadily increased but the problem of fraudulent and deceptive emails has not abated. It would seem that if senders used these technologies, then email receivers would easily be able to differentiate the fraudulent messages from the ones that properly authenticated to the domain. Unfortunately, it has not worked out that way for a number of reasons.

• Many senders have a complex email environment with many systems sending email, often including 3rd party service providers. Ensuring that every message can be authenticated using SPF or DKIM is a complex task, particularly given that these environments are in a perpetual state of flux.
• If a domain owner sends a mix of messages, some of which can be authenticated and others that can’t, then email receivers are forced to discern between the legitimate messages that don’t authenticate and the fraudulent messages that also don’t authenticate. By nature, spam algorithms are error prone and need to constantly evolve to respond to the changing tactics of spammers. The result is that some fraudulent messages will inevitably make their way to the end user’s inbox.
• Senders get very poor feedback on their mail authentication deployments. Unless messages bounce back to the sender, there is no way to determine how many legitimate messages are being sent that can’t be authenticated or even the scope of the fraudulent emails that are spoofing the sender’s domain. This makes troubleshooting mail authentication issues very hard, particularly in complex mail environments.
• Even if a sender has buttoned down their mail authentication infrastructure and all of their legitimate messages can be authenticated, email receivers are wary to reject unauthenticated messages because they cannot be sure that there is not some stream of legitimate messages that are going unsigned.

The only way these problems can be addressed is when senders and receivers share information with each other. Receivers supply senders with information about their mail authentication infrastructure while senders tell receivers what to do when a message is received that does not authenticate.

In 2007, PayPal pioneered this approach and worked out a system with Yahoo! Mail and later Gmail to collaborate in this fashion. The results were extremely effective, leading to a significant decrease in suspected fraudulent email purported to be from PayPal being accepted by these receivers.

The goal of DMARC is to build on this system of senders and receivers collaborating to improve mail authentication practices of senders and enable receivers to reject unauthenticated messages.

DMARC and the Email Authentication Process

DMARC is designed to fit into an organization’s existing inbound email authentication process. The way it works is to help email receivers determine if the purported message “aligns” with what the receiver knows about the sender. If not, DMARC includes guidance on how to handle the “non-aligned” messages. For example, assuming that a receiver deploys SPF and DKIM, plus its own spam filters, the flow may look something like this:

In the above example, testing for alignment according to DMARC is applied at the same point where ADSP would be applied in the flow. All other tests remain unaffected.

At a high level, DMARC is designed to satisfy the following requirements:

• Minimize false positives.
• Provide robust authentication reporting.
• Assert sender policy at receivers.
• Reduce successful phishing delivery.
• Work at Internet scale.
• Minimize complexity.

It is important to note that DMARC builds upon both the DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF) specifications that are currently being developed within the IETF. DMARC is designed to replace ADSP by adding support for:

• wildcarding or subdomain policies,
• non-existent subdomains,
• slow rollout (e.g. percent experiments)
• SPF
• quarantining mail

Anatomy of a DMARC resource record in the DNS

DMARC policies are published in the DNS as text (TXT) resource records (RR) and announce what an email receiver should do with non-aligned mail it receives.

Consider an example DMARC TXT RR for the domain “sender.dmarcdomain.com” that reads:

"v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@dmarcdomain.com"

In this example, the sender requests that the receiver outright reject all non-aligned messages and send a report, in a specified aggregate format, about the rejections to a specified address. If the sender was testing its configuration, it could replace “reject” with “quarantine” which would tell the receiver they shouldn’t necessarily reject the message, but consider quarantining it.

DMARC records follow the extensible “tag-value” syntax for DNS-based key records defined in DKIM. The following chart illustrates some of the available tags:

Tag Name	Purpose	Sample
v	Protocol version	v=DMARC1
pct	Percentage of messages subjected to filtering	pct=20
ruf	Reporting URI for forensic reports	ruf=mailto:authfail@example.com
rua	Reporting URI of aggregate reports	rua=mailto:aggrep@example.com
p	Policy for organizational domain	p=quarantine
sp	Policy for subdomains of the OD	sp=reject
adkim	Alignment mode for DKIM	adkim=s
aspf	Alignment mode for SPF	aspf=r

NOTE: The examples in this chart are illustrative only and should not be relied upon in lieu of the specification. 

How Senders Deploy DMARC in 5-Easy Steps

DMARC has been designed based on real-world experience by some of the world’s largest email senders and receivers deploying SPF and DKIM. The specification takes into account the fact that it is nearly impossible for an organization to flip a switch to production. There are a number of built-in methods for “throttling” the DMARC processing so that all parties can ease into full deployment over time.

1. Deploy DKIM & SPF. You have to cover the basics, first.
2. Ensure that your mailers are correctly aligning the appropriate identifiers.
3. Publish a DMARC record with the “none” flag set for the policies, which requests data reports.
4. Analyze the data and modify your mail streams as appropriate.
5. Modify your DMARC policy flags from “none” to “quarantine” to “reject” as you gain experience.

 

Failover Cluster Windows 2012

Failover clusters in Windows Server 2012 provide a high-availability solution for many server roles and applications.
By implementing failover clusters, you can maintain application or service availability if one or more computers in the failover cluster fails.
There are a lot of information that you can digest on the Failover Clustering, for more information please log in to :
http://technet.microsoft.com/en-us/library/hh831579.aspx
For this Failover Clustering demo, i will be using 4 VM’s, which is domain controller and 3 member server. Please refer to the screenshot :


1st : our 1st step is to configure a Failover Cluster, which is in this step i will connect a cluster nodes to the iSCSI targets…
Scenario for this demo is very simple :
“Your organization has important applications and services that the company wants to make highly available.
Some of these services cannot be made redundant by using NLB, so you decide to implement failover clustering.
Because iSCSI storage is already in-place, you decide to use the iSCSI storage for failover clustering.
First, you will implement the core components for failover clustering and validate the cluster, and then you will
create the failover cluster.”

1 – For this configuration i will be using my OSI-SVR3 member server, on OSI-SVR3, open Server Manager, click Tools, and then click the iSCSI Initiator…

2 – In the Microsoft iSCSI interface, just click Yes…

3 – on the iSCSI initiator Properties interface, click the Discovery tab and then click Discover Portal…
** Internet SCSI (iSCSI) initiator –> to established a connection with an iSCSI target


4 – In the IP address or DNS name box, type 172.16.0.21, and then click OK…
172.16.0.21 – OSi-SVR1 server

5 – Next, click the Targets tab, and click Refresh…
** In the Targets list, select iqn.1991-05…., and then click Connect…

6 – then cllick Add this connection to the list of Favorite Targets, and then click OK two times…

** Please repeat the step 1 – 6 on your SVR4 server…
7 – Switch to SVR3 and open Computer Management and make sure that you have few disk already attach to your Server to stimulate this demo, for this demo i have 3 VHD that i attach previously on the SVr3 server, all 3 disk having 30GB space each, you may choose your own space.


8 – Switch to SVR4 and please make sure also that you have the same disk configuration…
** make sure that all the disk is online (Right-click Disk 1, and then click Online)….

2nd : Let install the failover clustering feature on our SVR3 server….
1 – Open Server Manager and continue with add roles & feature until you reach Select features interface, then click Failover Clustering and continue with installation…

2 – next on the Confirm installation selections interface, click Install…

3 – Once installation complete, click Close…

** Repeat steps 1 – 3 on SVR4 server…
4 – Now we need to validate the both servers for failover clustering, on the SVR3 server open Failover Cluster Manager…

5 – On the right pane of Failover Cluster Manager, click Validate Configuration…

6 – In the Validate a Configuration Wizard interface, click Next…

7 – On the Select Servers or a cluster interface, please add our SVR3 & SVR4 and then click Next…

8 – On the Testing options interface, click Run all tests (recommended) and then click Next…

9 – On the Confirmation interface, click Next…

10 – This process might take up to 5 – 10 minutes…

11 – Once the validation tests to finish, on the Summary page, click View Report…

12 – Just verify that all tests completed…


3rd : Our next step is to create the failover cluster…
1 – in the Failover Cluster Manager, click Create Cluster….

2 – then click Next…

3 – On the Select Servers interface, make sure you add SVR3 & SVR4 in the selected servers and then click Next…

4 – In Access Point for Administering the Cluster interface, in the Cluster Name box, type OSICluster1.
** Under Address, type 172.16.0.125, and then click Next.

5 – In the Confirmation box, verify the information, and then click Next…

6 – On the Summary interface, click Finish…

4th : Configuring CSV
” Cluster Shared Volumes (CSV) enable multiple nodes in a failover cluster to simultaneously have read-write access to the same LUN (disk) that is provisioned as an NTFS volume.
With CSV, clustered roles can fail over quickly from one node to another node without requiring a change in drive ownership, or dismounting and remounting a volume.
CSV also help simplify the management of a potentially large number of LUNs in a failover cluster.”
1 – On SVR3 server, in the Failover Cluster Manager console, expand cluster1.Adatum.com, expand Storage, and then click Disks.
** locate a disk that is assigned to Available Storage. You can see this in the Assigned To column.
** Right-click that disk, and then click Add to Cluster Shared Volumes.
** Verify that the disk is assigned to Cluster Shared Volume…


5th : Our next step is to deploy and configure Highly Available File Server…
1 – On the SVR4 server, open Server Manager, click add roles & features and continue to Select server roles and then select File Server,  then click Next 2 times…

2 – On the Confirmation interface, click Install…

3 – Next, switch back to SVR3 server, in the Failover Cluster Manager, expand Cluster1.adatum.com, right-click Roles, and then select Configure Role…

4 – click Next…

5 – On the Select Role interface, select File Server, and then click Next….

6 – On the File Server Type interface, click File Server for general use, and then click Next…

7 – On the Client Access Point interface, in the Name box, type OSI-FS, in the Address box, type 172.16.0.130, and then click Next…

8 – On the Select Storage interface, select the Cluster Disk 3 check box, and then click Next…

9 – On the Confirmation interface, click Next…

10 – click Finish…

6th : Next we going to add a shared folder to a highly available File Server…
1 – Switch to SVR4 server and open Failover Cluster Manager…
** Expand Cluster1.Adatum.com, and then click Roles.
** Right-click OSI-FS, and then select Add File Share…


2 – In the Select the profile for this share interface, click SMB Share – Quick, and then click Next…

3 – On the Select the server and the path for this share interface, verify the server & Volume to share and then click Next…

4 – On the Specify share name interface, in the Share name box, type OSI-Docs, and then click Next…

5 – On the Configure share settings interface, do not make any changes, and then click Next…

6 – On the Specify permissions to control access interface, click Next…

7 – On the Confirm selections interface, click Create…

8 – On the View results interface, click Close…

9 – Next we need to configure failover and failback settings, on the Failover Cluster Manager, click Roles, right-click OSI-FS, and then click Properties…
“** Failover transfers the responsibility of providing access to resources in a cluster from one node to another. Failover can occur when an administrator intentionally moves resources to another node for maintenance, or when unplanned downtime of one node happens because of hardware failure or other reasons. In addition, service failure on an active node can initiate failover to another node.”
“** The Cluster service can failback instances that were originally hosted on the offline node after the offline node becomes active again. When the Cluster service fails back an instance, it follows the same procedures that it performs during failover. That is, the Cluster service takes all the resources in the instance offline, moves the instance, and then brings all the resources in the instance back online.”


10 – Click the Failover tab and then click Allow failback…
** Click Failback between, and set values to 3 and 4 hours.


11 – Next, click the General tab, then select SVR3 and SVR4 as preferred owners and make sure you move SVR4 up, then click OK…

7th : Now we have to validate / verify the Deployment of our High Availability File Server
1 – Switch to DC01 server (Domain Server), try access to \\osi-fs\osi-docs…
** Verify that you can access the location and that you can open the osi-docs folder…

2 – To verify you can create a any text document inside this folder…

3 – Next, switch back to SVR3 server and open the Failover Cluster Manager.
** Expand Cluster1.adatum.com, and then click Roles. Note the current owner of OSI-FS (SVR3)
** Right-click OSI-FS, click Move, and then click Select Node…

4 – In the Move Clustered Role box, select the cluster node (it will be either SVR3 or SVR4), and then click OK…

5 – Verify that SVR4 has moved to a new owner…
** I do recommend that you switch back to DC1 server and verify that you can still access the \\osi-fs\osi-docs…

6 – Next, in the Failover Cluster Manager, right-click the node (I choose SVR4) , select More Actions, and then click Stop Cluster Service…

7 – Verify that SVR4 now is down…

8 – Verify also OSI-FS has moved to another node which is SVR3…
** ** I do recommend that you switch back to DC1 server again and verify that you can still access the \\osi-fs\osi-docs…

9 – switch back to SVR3 server and on the Failover Cluster Manager, click Nodes. Right-click the stopped node which the SVR4, select More Actions, and then click Start Cluster Service…

10 – Verify all nodes status now up…

11 – Next, expand Storage, and then click Disks.
In the center pane, right-click the disk that is assigned to Disk Witness in Quorum then click Take Offline…
“** Quorum is the number of elements that must be online for a cluster to continue running. In effect, each element can cast one vote to determine whether the cluster continues to run. Each cluster node is an element that has one vote. In case there is an even number of nodes, then an additional element, which is known as a witness, is
assigned to the cluster. The witness element can be either a disk or a file share. Each voting element contains a copy of the cluster configuration; and the Cluster service works to keep all copies synchronized at all times.”


12 – then click Yes…

13 – Switch to DC1 server and verify that you can still access the \\osi-fs\osi-docs location. By doing this, you
verified that the cluster is still running, even if the witness disk is offline…

14 – Now switch back to SVr3 server, in Failover Cluster Manager, expand Storage, click Disks, right-click the disk that is in Offline status, and then click Bring Online…

15 – Next, right-click Cluster1.Adatum.com, select More Actions, and then click Configure Cluster Quorum Settings…

16 – click Next…

17 – On the Select Quorum Configuration Option interface, click Advanced quorum configuration, and then click Next…

18 – On the Select Voting Configuration interface,Do not make any changes, and then click Next…

19 – On the Select Quorum Witness interface, select Configure a disk witness and then click Next…

20 – On the Configure Storage Witness interface, select Cluster Disk 3, and then click Next…

21 – click Next…

22 – click Finish…
** we have succesfully tested the failover scenarios and next we going to configure CAU

8th : Configure CAU – Cluster-Aware Updating
** Cluster-Aware Updating (CAU) is a technology in Windows Server 2012 that automatically updates cluster nodes with Windows Update hotfix, by keeping the cluster online, and minimizing downtime.
** During an update procedure, CAU transparently takes each cluster node offline, installs the updates and any dependent updates, and then performs a restart if necessary. CAU then brings the node back online, and moves to update the next node in a cluster.
1 – Before we proceed, please make sure that you have install Failover Clustering feature in DC1 Domain Server…
2 – Switch back to SVR3 & SVR4 server, and please verify also that Inbound Rule for Remote Shutdown (RPC-EP-In) & Inbound Rule for Remote Shutdown (TCP-In) rule is enabled…

3 – let’s return to DC1 domain server and open Cluster-Aware Updating console…

4 – In the Cluster-Aware Updating interface, in the Connect to a failover cluster drop-down list box, select OSICLUSTER1, and then click Connect…

5 – In the Cluster Actions pane, click Preview updates for this cluster…

6 – In the OSICluster1-Preview Updates interface, click Generate Update Preview List…

7 – After few minutes, updates will display in the list and then click Close…

8 – still on the DC1 server, now we need to update the failover cluster and configure the self-updating…
** in the Cluster-Aware Updating console, click Apply updates to this cluster…

9 – On the Getting Started interface, click Next…

10 – On the Advanced options interface, review the options for updating, and then click Next…

11 – On the Additional Update Options interface, click Next…

12 – On the Confirmation interface, click Update, and then click Close…

13 – In the Cluster nodes pane, you can review the progress of the updating process…
** Please take note that 1 node of the cluster is in a waiting state, and the other node is restarting after it is updated.
** Wait until the process is finished and both nodes will restarted automatically.


14 – The process is finished when both nodes show Succeeded…

15 – Once the SVR3 restarted, log in as administrator and open Cluster-Aware Updating…
** In the Cluster-Aware Updating box, in the Connect to a failover cluster drop-down list box, select OSICLUSTER1. Click Connect….

16 – Click the Configure cluster self-updating options in the Cluster Actions pane…

17 – On the Getting Started interface, click Next…

18 – On the Add CAU Clustered Role with Self-Updating Enabled interface, click Add the CAU clustered role, with self-updating mode enabled, to this cluster, and then click Next…

19 – On the Specify self-updating schedule page,configure your own schedule and then click Next…

20 – On the Advanced Options interface, click Next…

21 – On the Additional Update Options interface, click Next….

22 – On the Confirmation interface, click Apply…

23 – After the clustered role is added successfully, click Close and we have successfully configured CAU.


That’s all for now.. i know its a long step, but i hope for those who taking MCSA exam code 70-412, you should do a lot of exercises on the Failover Cluster.

Most IMP:  Quorum part is the most tricky configuration in Windows Failover Cluster Server. Try to have the best possible understanding of it in order to avoid the confusion at the time of troubleshooting WFSC issues or  while creating/Validating the WFCS